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(57) Abstract: The invention concerns a system for consulting and/or updating a record stored in a first database (33, 36), said record 
comprising one or several resource records (RR), said first database being hosted by a domain name server, called DNS (Domain 
Name System) server, or a directory server, called LDAP (Lightweight Directory Access Protocol) server, capable of being accessed 
by indirection from a DNS server. The system comprises: communication means (1150, 53-59, 61, 63) enabling reception by said 
system from a telecommunication terminal a request for consulting and/or modifying said record or for programming such a request; 
control means (1 175, 74, 75). for determining based on said consultation and/or modification request transmitted to said system or 
pre-programmed in said system, a domain name and an operation to be performed on said record; protocol management means 
(1 162, 62, 64) for searching based on said name domain, the IP address of said server hosting said first database and, based on said 
operation, for transmitting to said server a request for reading or updating said record. The DNS protocol module acts as a standard 
RESOLVER software. The invention is useful in the context of ENUM service enabling any subscriber's E.164 format telephone 
number to be associated with other services. The resource records contain therefor several NAPTR (Naming Authority Poin TeR) 
fields referring to an e-mail address, a Web site URL, a fax number or a VoIP or mobile telephone. 
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tions t se referer aux "Notes explicatives relatives aux codes et 
abreviations" figurant au debut de chaque numero ordinaire de 
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(57) Abrege : V invention conceme un systeme de consultation et/ou de mise a jour d'un enregistrement stocke* dans une premiere 
base de donnees (33, 36), ledit enregistrement comprenant un ou une pluralite d'enregistrements de ressources (RR), ladite premiere 
base de donnees etant hebergee par un serveur de noms de domaine, dit serveur DNS, Domaine Name System, ou un serveur d'an- 
nuaire, dit serveur LDAP, Lightweight Directory Access Protocol, pouvant etre accede par indirection a partir d'un serveur DNS. 
Le systeme comprend: - des moyens de communication (1150, 53-59, 61, 63) permettant audit systeme de recevoir d'un terminal 
de telecommunication une demande de consultation et/ou de modification dudit enregistrement ou une programmation d'une telle 
demande; - des moyens de contrdle (1 175, 74, 75) adaptes a determiner a partir de ladite demande de consultation et/ou de modifi- 
cation transmise audit systeme ou prealablement programmee dans ledit systeme, un nom de domaine et une operation a effectuer 
sur ledit enregistrement; - des moyens de gestion de protocole (1162, 62, 64) adapts a rechercher a partir dudit nom de domaine, 
radresse IP dudit serveur h£bergeant ladite premiere base de donnees et, en fonction de ladite operation , a transmettre audit serveur 
une requete de lecture ou de mise a jour dudit enregistrement Le module protocole DNS joue le role classique d'un logiciel RESOL- 
VER. U invention est utilisable dans le cadre du service ENUM permettant a tout abonnee d'associer son numero de telephone au 
format E.164 a d'autres services. Les RR (Resource Record) contiennent a cet effect plusieurs champs NAPTR (Naming Authority 
PoinTer) faisant reference a une adresse eMail, un URL de site web, un numero de fax ou de telephone VoIP ou mobile. 
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I 

SYSTEME DE CONSULTATION ET/OU MISE A JOUR DE SERVEURS DNS ET/OU D'ANNUAIRES LDA 
P 



La presente invention concerne un systeme de consultation et /ou mise a jour de 
serveurs DNS (Domain Name System) et/ou d'annuaires LDAP (Lightweight 
Directory Access Protocol) a partir d'un terminal. La presente invention permet 
notamment a un abonne, a partir d'un terminal quelconque, de consulter et de mettre 
5 a jour un enregistrement de ressources de telecommunication stocke dans un serveur 
DNS ou LDAP. 

Les serveurs DNS (et LDAP) sont utilises dans le monde informatique pour 
nommer des machines (par exemple: association d'une URL web a une adresse IP 
correspondant au serveur web hebergeant ce site web). Ces serveurs sont 

10 habituellement consultes par des machines informatiques au moyen d'un logiciel 
communement appele RESOLVER, disponible dans la purpart des terminaux ou 
serveurs informatiques. Ce logiciel permet d'extraire une information d'un serveur 
DNS en reponse a la requete d'un client. Cette information peut etre disponible 
directement aupres du premier serveur DNS consulte ou bien aupres d'un serveur 

15 DNS reference par le premier, et ainsi de suite si necessaire par indirections 
successives. Les contenus des serveurs DNS sont mis a jour par des specialistes 
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"administrateur" et de maniere peu frequente (mise a jour de fichiers a plat sous 
plateforme UNIX ou application dediee via IHM sous les plate-formes serveurs 
Windows). Le format des contenus des serveurs et des requetes sont definis dans un 
protocole, dit protocole DNS decrit dans les documents RFC 1034 et RFC 1035, 
5 disponibles sur le site web de 1'IETF (www.ietf.org). 

D'autre part, les serveurs DNS sont desormais appeles a jouer un role dans le 
cadre du service ENUM visant a offrir aux abonnes une portabilite generalisee de 
numero de telephone. Ce service ENUM utilise le systeme de numerotation 
telephonique international defini par l'UIT sous la recommandation E.164. Plus 
10 precisement, le service ENUM permet a tout abonne disposant d'une numero 
telephonique unique E.164 (numero de telephone de type +33296053859) d'etre joint 
par differents moyens en fonction de ses preferences configurees dans un profil 
heberge dans le reseau par un serveur DNS. Par exemple, le numero de telephone 
unique E.164 de l'abonne ENUM peut etre associe a un numero de telephone mobile 
15 (+33686166924), a un numero de telephone fixe (+33296916404), a une adresse 
eMail foertrand.dupont@jd.francetelecom.com> . a une URL de site web 
rhttp://www.bertrand.duDont.com\ a un numero de telephone VoIP 
(sip:bertrand.dupont@sip.francetelecom.com), a un numero de fax, etc. 

L'ensemble de ces informations peuvent etre stockees dans un serveur DNS 
20 standard et accedees selon le modele de delegation hierarchique represente en Fig. 1 . 

L'acces se fait par un serveur DNS racine (E164.ARPA). Chaque pays dispose 
ensuite d'un code telephonique unique (33 pour la France) et un serveur DNS est gere 
au niveau 1 par chaque pays (3.3.E164.ARPA pour la France). Des operateurs de 
telecommunications ou des fournisseurs de services ENUM gerent enfin des serveurs 
25 DNS (indique en Fig. 1 par DNS 1 a DNS 6) en fonction des ressources telephoniques 
(tranche de numeros telephoniques E.164) qui leur sont attribuees. Le modele retenu 
est un decoupage par tranches: 5 tranches de num6ros de telephone fixes RTC avec 
des prefixes allant de 1 a 5 et une tranche de numeros de telephone mobile identifiee 
par le ptefixe 6. 

30 A un numero de telephone au format E.164, est associe un chemin dans 

l'arborescence des serveurs DNS. Plus precisement, chaque numero de telephone au 
format international E.164 est inverse, le code est supprime, un point est ajoute 
entre chaque chiffre et le resultat obtenu est accole au domaine el64.arpa de maniere a 
transformer le numero de telephone en un nom de domaine Internet unique. Par 
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exemple, le numero de telephone +33686166924 donne apres transformation, le nom 
de domaine Internet 4.2.9.6.6. 1.6.8.6.3.3.el64.arpa. 

D' autre part, a chaque numero de telephone au format E.164 est associe un 
enregistrement comprenant un ou des enregistrements de ressources (Resource Record 

5 ou RR), stockes dans le serveur de niveau 2 correspondant, chaque enregistrement de 
ressource pouvant comprendre un ou plusieurs champs. Par exemple, a un numero de 
telephone au format E.164 peuvent etre associes des enregistrements de ressource 
NAPTR (Naming Authority PoinTeR), tels que definis dans les documents RFC 2915 
et RFC 2916, disponibles sur le site de 1'IETF. De maniere schematique, un 

10 enregistrement de ressource NAPTR indique un service de telecommunication (n° de 
tel, fax, adresse eMail, site web etc.) associe a un niveau de priority. On appellera par 
la suite enregistrement ENUM (ou profil ENUM) un ensemble d' enregistrements 
NAPTR associes a un nom de domaine Internet. Par exemple, si le profil ENUM 
suivant est stock6 dans un serveur DNS de niveau 2 : 

15 

SORIGIN 9.5.8.3.5.0.6.9.2.3.3.el64.arpa. 

IN NAPTR 100 10 "u" "tel+E2U" "! A .*$!tel:+33296053859!" 
INNAPTR100 11 "u" "tel+E2U" "! A .*$!tel:+33296916404!" 
IN NAPTR 100 12 "u" "tel+E2U" "! A .*$!tel:+33686 166924! 
20 IN NAPTR 100 13 "u" "sip+E2U" "! A .*$!sip:bdupont@sip.ftrd.fr!" 

IN NAPTR 120 10 "u" "mailto+E2U" "! A .*$!mail2:bdupont@rd.ftrd.fr!" 
IN NAPTR 130 10 "u" "http+E2U" "! A .n!http://www.bdupont.fr!" 

La ligne d'en-tete indique un nom de domaine Internet correspondant au numero 
25 de telephone E.164. Le logiciel RESOLVER permet a partir du nom de domaine 
d'acceder a 1' enregistrement. A chaque enregistrement NAPTR de l'exemple ci- 
dessus correspond une ressource ou service de telecommunication. Deux champs 
numeriques suivent le terme « NAPTR », il s'agit respectivement des priorites de 
service: "Ordre" et "Preference". Plus la valeur du champ "Ordre" est faible, plus le 
30 service est prioritaire et si plusieurs services ont un niveau d'ordre identique, plus la 
valeur de Preference associee est faible, plus le service est prioritaire. Ainsi, les lignes 
de l'enregistrement ci-dessus correspondent a des priorites decroissantes. 

La l* rc ligne correspond au service telephonique fixe 0296053859 avec un 
ordre=100 et une preference =10. 
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La 2 4me ligne correspond au service telephonique fixe 0296916404 avec un 
ordre=l 00 et une pref6rence=l 1 . 

La 3' me ligne correspond au service telephonique mobile 0686166924 avec un 
ordre=100 et une pref£rence=12 . 
5 La 4 4mc ligne correspond au service telephonique IP via SIP vers l'adresse SIP 

hHu pont@siD.ftrd.fr avec un ordre=100 et une preference=13 . 

La 5 4me ligne correspond au service de courrier electronique eMail dont l'adresse 
de destination est bdupont@rd.ftrd.fr avec un ordre=120 et une preference==10 . 

Enfin, la 6 4me ligne correspond au service web dont l'URL d'acces est 
10 http://www.bdupont.fr avec un ordre=130 et une preference=10 . 

La signification de cet enregistrement est la suivante. Si Ton cherche a joindre le 
num6ro de telephone E.164 (+33296053859), le logiciel RESOLVER transmet une 
requSte au serveur DNS niveau 2 avec le nom de domaine Internet correspondent 
(9.5.8.3.5.0.6.9.2.3.3.el64.arpa). En retour, le serveur DNS niveau 2 (DNS2) fournira 
15 dans la reponse la liste des ressources de telecommunication (egalement denommes 
ci-apres services) assoctes au numero de telephone +33296053859, telle que donn<§ 
par Tenregistrement. Le logiciel RESOLVER et le service ENUM pourront alors 
exploiter tout ou partie de ces ressources en mode sequentiel (le systeme tentera de 
joindre le service le plus prioritaire puis, en l'absence de reponse ou en cas 
20 d'occupation, le systeme essaiera de joindre le service de moindre priorite, etc.) ou en 
mode diffusion (le service ENUM tentera alors de joindre simultanement l'ensemble 
des services). 

La modification des profils ENUM dans un serveur DNS s'accommode mal du 
precede de mise a jour par administrateur tel que connu de l'etat de la technique. En 

25 effet, au contraire des noms de domaines Internet, les services classiques de 
telecommunication tels que le telephone ou la telecopie sont susceptibles de 
modification frequente. Qui plus est, il est quelquefois necessaire de programmer ces 
modifications de maniere automatique sur une base quotidienne voire horaire. II est 
alors extremement difficile pour des raisons de disponibilitf et de flexibilite de faire 

30 supporter la modification de configuration d'un profil ENUM a son propre operateur 
de telecommunications ou a son fournisseur de service ENUM. 

Un probteme particulier a ia base de i'invention est de pemiettre a un abonne 
une consultation et/ou une modification simple et rapide de son profil ENUM stocke 
dans un serveur DNS ou un annuaire LDAP. 
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De maniere plus gendrale, le probleme a la base de l'invention est de permettre 
une consultation et/ou modification simple et rapide d'un ou de plusieurs 
enregistrement(s) de ressource stocke(s) dans un serveur DNS ou LDAP et ce, a partir 
d'un terminal conventionnel quelconque. 

5 Le probleme a la base de l'invention est resolu par un systeme de consultation 

et/ou de mise a jour d'un enregistrement stocks dans une premiere base de donnees, 
ledit enregistrement comprenant un ou une pluralite d'enregistrements de ressources, 
ladite premiere base de donnees &ant hebergee par un serveur de noms de domaine, 
dit serveur DNS, ou un serveur d'annuaire, dit serveur LDAP, pouvant etre accede par 

1 0 indirection a partir d'un serveur DNS, ledit systeme comprenant: 

- des moyens de communication permettant audit systeme de recevoir d'un 
terminal de telecommunication une demande de consultation et/ou de modification 
dudit enregistrement ou une programmation d'une telle demande ; 

- des moyens de controle adaptes a determiner a partir de ladite demande de 
15 consultation et/ou de modification transmise au dit systeme ou prealablement 

programmee dans ledit systeme, un nom de domaine et une operation a effectuer sur 

ledit enregistrement ; 

- des moyens de gestion de protocole adaptes a rechercher a partir dudit nom de 
domaine, l'adresse IP dudit serveur h6bergeant ladite premiere base de donnees et, en 

20 fonction de ladite op6ration, a transmettre au dit serveur une requete de lecture ou de 
mise a jour dudit enregistrement. 

Avantageusement, ledit systeme comprend des moyens d'authentification 
adaptes a authentifier au niveau applicatif l'emetteur de ladite demande a partir 
d'informations d'authentification stockees dans une seconde base de donnees locale 

25 ou distante. 

Lorsque l'6metteur de ladite demande a ete authentifie, lesdits moyens de 
gestion de protocole permettent de transmettre une requete en consultation selon le 
protocole DNS (DNS Query) audit serveur DNS, la requete ayant pour argument ledit 
nom de domaine, et a recevoir une premiere reponse dudit serveur. 
30 Selon un mode de realisation, les moyens de contr61e sont adaptes a determiner 

ledit nom de domaine a partir d'un identifiant d'abonn6 qui pourra etre le numero 
telephonique E.164 dudit abonne. 
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Les moyens de controle sont alors adaptes a extraire des informations et a 
determiner en fonction de ladite demande une operation a effectuer sur un 
enregistrement de ressource de type NAPTR. 

Selon d'autres modes de realisation les moyens de controle sont adaptes a 
5 extraire des informations et a determiner en fonction de ladite demande une operation 
a effectuer sur un ou plusieurs enregistrements de ressource de type A, NS, MD, MF, 
CNAME, SOA, MB, MG, MR, NULL, WKS, PTR, HINFO, MINFO,MX, TXT. 

Les caracteristiques de l'invention mentionnees ci-dessus, ainsi que d'autres, 
10 apparaitront plus clairement a la lecture de la description suivante d'un exemple de 
realisation, ladite description etant faite en relation avec les dessins joints, parmi 
lesquels : 

la Fig. 1 illustre schematiquement le modele de delegation utilise dans le service 
ENUM; 

15 la Fig. 2 A illustre schematiquement un exemple d'environnement du systeme 

selon P invention; 

la Fig. 2B illustre schematiquement l'environnement de la Fig. 2A dans le 

contexte du service ENUM ; 

la Fig. 3A represente le schema de principe du systeme de consultation/ mise a 

20 jour selon l'invention ; 

la Fig. 3B represente un exemple de systeme de consultation/ mise a jour selon 

l'invention ; 

la Fig. 4 represente schematiquement une procedure de consultation et mise a 
jour manuelle d'un profil ENUM avec acces en mode vocal ; 
25 la Fig. 5 represente schematiquement une procedure de consultation et mise a 

jour manuelle d'un profil ENUM par envoi de messages SMS ; 

la Fig. 6 represente schematiquement une procedure de consultation et mise a 
jour manuelle d'un profil ENUM par le Web ; 

la Fig. 7 represente schematiquement une procedure de consultation et mise a 
30 jour manuelle d'un profil ENUM a partir d'un Minitel; 

la Fig. 8 represente schematiquement une procedure de consultation et mise a 
jour manuelle d'un profil ENUM par eMail; 

la Fig. 9 represente schematiquement une procedure de consultation et mise a 
jour manuelle d'un profil ENUM par IUU a partir d'un terminal RNIS; 
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la Fig. 10 represente schematiquement une procedure de programmation de mise 
automatique de profil ENUM ; 

la Fig. 11 represente schematiquement une procedure de mise a jour 

automatique de profil ENUM; 
5 la Fig. 12 represente schematiquement une procedure de consultation de profil 

ENUM lorsque ce dernier est stocke dans un annuaire LDAP ; 

la Fig. 13 represente schematiquement une procedure de mise & jour de profil 
ENUM lorsque ce dernier est stocke dans un annuaire LDAP. 

10 La Figure 2A illustre un exemple d'environnement du systeme selon rinvention. 

Des fournisseurs de service de gestion de ressources de telecommunication, ci- 

apres denomm£s fournisseurs de service, ont ete schematiquement representes en 

30i,...,30n. Chaque fournisseur de service dispose d'un serveur DNS (310 ou LDAP 

(34i) hebergeant une base de donnees et plus generalement de plusieurs serveurs 
15 redondants de mantere a augmenter la fiabilite de l'acces au service. La base de 

donnees contient un enregistrement des ressources de telecommunication pour tous les 

abonnes du fournisseur de service en question. 

Le systeme (50) selon l'invention peut etre connecte d'une part au reseau 

teiephonique public via une interface standard de type analogique ou numerique TO ou 
20 T2 et, d'autre part, au reseau IP via une interface standard de type Ethernet. 

Plus precisement, le systeme (50) est connecte au reseau Internet si la presente 

invention est accessible & tout abonne, quel que soit son fournisseur de service, et 

pourra etre connect* a un reseau Intranet si la presente invention est accessible aux 

seuls abonnes d'un fournisseur de service. 
25 Le systeme (50) pourra etre accede par un terminal teiephonique RNIS (2) 

connecte soit directement soit a travers un PABX (3) au r6seau RNIS (10). On 

rappelle que le r6seau RNIS est interconnect* nativement au reseau RTC. 

Le systeme (50) pourra aussi etre accede par un terminal teiephonique classique 

(4) ou un terminal Minitel (5) connecte au reseau RTC (11). 
30 Le systeme (50) pourra encore etre accede par un terminal mobile GSM (6) ou 

encore un terminal UMTS non represente (les reseaux GSM et UTRAN sont 

interconnectes nativement au reseau RTC). 

Le systeme (50) pourra etre accede au moyen d'un terminal teiephonique IP (7) 

connecte au reseau IP (13). 
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Le systeme (50) pourra enfin etre accede au moyen d'un micro-ordinateur (8) 
relie au reseau IP soit au travers une interface Ethernet (reseau local d'entreprise) soit 
par modem (RTC/RNIS/ADSL/cable/satellite etc.) 

L'abonne pourra en outre recevoir des notifications du systeme (50) grace a l'un 
5 des terminaux envisages ci-dessus ou bien encore a l'aide d'un terminal fax (9). 

La Figure 2B illustre un exemple d'environnement du systeme selon 1' invention, 
dans le contexte d'un service ENUM. Les elements portant les memes numeros de 
reference sont identiques k ceux de la Fig. 2A. 

10 On a indiqu£ en 40 le serveur DNS ENUM de niveau 0 (racine). Ce serveur 

dispose de l'ensemble des adresses IP reTerencant l'ensemble des serveurs DNS 
ENUM de niveau 1, correspondant aux codes des differents pays (33 pour la France, 
34 pour l'Espagne, 44 pour l'Angleterre, etc.). Par exemple, on a fait figurer en 41 le 
serveur DNS ENUM de niveau 1 correspondant a la France. 

15 Chaque operateur ou fournisseur de service ENUM dispose d'au moins un 

premier serveur DNS ENUM de niveau 2 (310, dit serveur primaire, redonde par au 
moins un second serveur DNS ENUM de niveau 2 <31"0, dit serveur secondaire, ce 
afin d'assurer une bonne fiabilite de service. Le serveur primaire (resp. secondaire) 
heberge une base de donnees 33j (resp. 33'i). Dans chaque serveur de niveau 2, est 

20 stocke, pour chaque numero de telephone E. 1 64 d'abonne au service ENUM, un profil 
compose des differentes ressources de tel6communication de l'abonne\ chaque 
ressource correspondant a un moyen d'acces (par ex. telephone fixe bureau, telephone 
fixe domicile, telephone mobile, telephone IP, adresse eMail du bureau, adresse eMail 
du mobile, N° de fax professionnel, etc.) ainsi que les priorites afferentes a chacun de 

25 ces moyens d'acces. Chaque ressource de telecommunication est declaree au moyen 
d'un enregistrement de ressource NAPTR comme on l'a vu plus haut. La priorite 
d'une ressource est determinee par le contenu des champs Ordre et Preference de 
l'enregistrement de ressource NAPTR, tels que definis dans le document RFC 2915 de 
PIETF et exemplifies dans la partie introductive. 



30 



Un fournisseur A de service ENUM (300 peut egalement disposer d'un serveur 
LDAP (34j) hebergeant un annuaire dynamique LDAP (360 tei <l ue defini dans le 
document RFC 1959 de 1'IETF. L'interet de cette configuration est de permettre de 
g6rer les profils ENUM par indirection non plus dans le DNS ENUM niveau 2 mais 
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dans l'annuaire dynamique LDAP. L'avantage procure consiste a ne plus modifier le 
profil du client ENUM au niveau du serveur DNS ENUM niveau 2 mais directement 
dans l'annuaire LDAP qui, lui, est concu pour stocker des profils dynamiques. Dans ce 
cas, le DNS ENUM niveau 2 (310 contient par exemple le profil suivant pour 
l'ensemble des numeros de telephone E.164 commencant par le prefixe "+332": 

SORIGIN 2.3.3.el64.arpa. 
INNAPTR100 10 "u" "ldap+E2U" 
"!^+332(.*)$!ldap://ldap.fournisseurA.fr/cn=01!" 

L'annuaire LDAP (36j) est accede par indirection a partir du serveur DNS 
ENUM de niveau 2 et contient les enregistrements de ressource pour les differents 
abonnes du fournisseur A. 

15 Un serveur ou une passerelle ENUM (80) peut consulter un fournisseur de 

service ENUM (30i) pour connaitre la liste des ressources de telecommunication d'un 
abonne ENUM. Pour ce faire, le logiciel RESOLVER transforme le numero unique 
E.164 de l'abonne en nom de domaine comme on l'a vu plus haut et accede par 
indirections successives au serveur DNS ENUM niveau 2 (3L) et, le cas echeant, 

20 apres indirection supplemental au serveur LDAP (34;). Le fournisseur de service 
retoume la liste des ressources de l'abonne en question avec les priorites associees. Le 
serveur ou la passerelle ENUM (80) peut alors, selon le cas, tenter de joindre l'abonne 
en utilisant successivement les ressources, par ordre decroissant de priorite ou joindre 
l'abonne au moyen de l'ensemble de ses ressources. 



25 



La Fig. 3A represente le schema de principe du systeme (50) de mise a jour 
selon 1' invention . 



Le systeme comprend des moyens de communication (1150) permettant a un 
30 abonne de dialoguer avec ledit systeme et notamment : 

de transmettre a l'abonne une requete en authentification ; 

de recevoir dudit abonne des informations permettant son 

authentification ; 
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de recevoir dudit abonne une demande de modification d'un 
enregistrement (dite demande manuelle) ou une demande de 
modification automatique (dite demande programmee) en fonction d'un 
critere temporel ou geographique ; 

de transmettre le contenu d'un enregistrement prealablement ou 
posterieurement a la demande de modification ; 

de transmettre au dit abonne une notification de confirmation de mise a 
jour lorsque la modification demandee a bien ete effectueeet 
d'infirmation de mise a jour lorsque cette derniere n'a pu etre effectuee; 
de transmettre au dit abonne, a fin de consultation ou revision, une 
demande de modification automatique prealablement enregistree dans 
ledit systeme ; 

de transmettre au dit abonne un historique des modifications effectuees. 

15 Le systeme cornprend egalement des moyens d'interface (1 160) permettant de 

connecter lesdits moyens de communication au reseau RTC/RNIS et/ou a un reseau IP 

(Internet ou Intranet). 

Le systeme cornprend encore des moyens d'authentification (1173) cooperant 
avec les moyens de communication pour authentifier au niveau applicatif un emetteur 
20 de demande de consultation et/ou mise a jour. L'authentification au niveau applicatif 
presente l'avantage de permettre a un abonne d'operer a partir de n'importe quel 
terminal. Us moyens d'authentification utilisent pour ce faire des informations 
d'authentification stockees dans une base de donnees (1 1 70) locale ou distante . 

25 Outre les informations susmentionnees, la base de donnees (1170) peut 

notamment contenir des programmes de modification automatique relatifs a differents 
abonnes, les adresses IP des serveurs des differents fournisseurs de gestion de 
ressources de telecommunication, les historiques de modifications manuelles ou 
automatiques des enregistrements, les adresses auxquelles les notifications de 

30 confirmation/infirmation de mise a jour doivent etre transmises. 

Le systeme (50) cornprend encore des moyens de gestion de protocole (1 162) 
assurant entres autres la fonction RESOLVER. En particulier les moyens de gestion 
de protocole sont adaptes a rechercher, le cas echeant par indirections successives, le 
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contenu d'un enregistrement de ressource (RR) a l'aide d'un nom de domaine. Les 
moyens de gestion de protocole peuvent transmettre a cette fin des requetes de 
consultation selon le protocole DNS (DNS Query). En outre, les moyens de gestion 
de protocole peuvent mettre a jour des enregistrements de ressources a partir de 

5 requetes de mise a jour (DNS Update). Selon un mode de realisation, si des 
enregistrements de ressources sont stockees dans un annuaire LDAP, les moyens de 
gestion de protocole permettront egalement la consultation d'un enregistrement dans 
un annuaire LDAP (emission d'une requete LDAP Search) ainsi que la mise a jour de 
cet enregistrement (emission d'une requete LDAP Modify). Lorsque la mise a jour a 

10 ete realisee, les moyens de protocole recoivent un acquittement du serveur du 
fournisseur de gestion de ressources de telecommunication. 

Les moyens de controle 1 175 coordonnent les moyens precites et notamment : 

j 5 _ ordonnent aux moyens de communication la transmission d'une requete 

en authentification ; 

apres authentification de l'abonne par les moyens d'authentification 
(1173) demandent aux moyens de protocole (1162) de transmettre une 
requete en consultation, formatent la reponse et la retransmettent sous 
20 forme intelligible a l'abonne via les moyens de communication; 

a partir d'une demande en modification d'un enregistrement de ressource 
par un abonne, determinent une operation a effectuer sur ledit 
enregistrement et un identifant de l'abonne 

sur reception de confirmation/infirmation de mise a jour par les moyens 
25 de protocole, notifient la confirmation/infirmation a l'abonne via les 

moyens de communication. 

La Fig. 3B illustre un exemple de realisation de l'invention dans le contexte 
d'un service ENUM. 

30 Les elements portant les memes numeros de reference sont identiques a ceux de 

la Fig. 2A. En particulier, l'abonne pourra contacter le systeme de mise a jour (50) au 
moyen de 1'un des terminaux envisages plus haut. En (30) a ete repr6sente un 
fournisseur de service de gestion de ressources de telecommunication comprenant un 
serveur DNS de niveau 2 (31), dit serveur primaire, redonde par un serveur secondaire 
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(non represent**). Le serveur (31) comporte une base de donnees (33) et une pile de 
protocole DNS (32) integrant les protocols DNS decrits dans les documents RFC 
1034 et RFC 1035. La pile de protocole integre egalement les protocoles DNS decrits 
dans les documents RFC 2136 et RFC 2137 destines a permettre la mise a jour (DNS 
5 Update) d'un enregistrement de ressource (RR). De maniere optionelle, le fournisseur 
de service de gestion de ressources comprend aussi un serveur d'annuaire LDAP (34) 
hebergeant une base de donnees (36). Le serveur d'annuaire LDAP comporte une pile 
de protocole LDAP (35). 

10 Les moyens de communication du systeme (50) sont constitues des modules 

suivants : , , , . 

o un module ayant en charge le traitement des appels telephoniques 

entrants et sortants (52). Ce module gere l'etablissement et la liberation 
de la communication ; 

j 5 o un module (53) de gestion d'Information dUsager a Usager (RJU) 

permettant d'extraire et de transmettre des informations IUU ; 
o un module (54) de traitement des codes DTMF. Ce module a en charge 

la recuperation des DTMF saisis par l'abonne ; 
o un module (55) de synthese vocale ; 
20 o un module (56) de diffusion de fichiers vocaux pre-enregistres et 

concatenes pour former des phrases ; 
o un serveur videotex (57) ; 
o un module de reception et d'envoi de SMS (58) ; 
o un module d'envoi de fax (59) ; 
25 o un serveur SMTP (6 1 ) permettant remission et la reception d'eMail ; 

o un serveur Web dynamique (63). 

II convient de noter que le systeme peut comprendre egalement un module de 
reconnaissance vocale (non represent) adapte a reconnaitre une information 
prononcee par l'abonn6. 

30 Les moyens de communication sont relies a l'exterieur au moyen d'une interface 

RTC et/ou RMS (51) et une interface IP (60). La premiere est basee soit sur une carte 
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analogique RTC multi-port soit sur une carte RMS TO (2 canaux) ou T2 (30 canaux). 
La seconde est une interface Ethernet. La passerelle indiquee par (14) rappelle que les 
reseaux RTC/RNIS et IP sont nativement interconnectes en protocole VOIP 
(H323/SIP). 

5 Le systeme (50) comporte, comme precedemment, des moyens 

d'authentification (73) autorisant l'authentification applicative des abonnes du service 
a partir d'informations d'authentification, par exemple des couples de pseudonymes 
(Loginjd) et de mots de passe stockes dans une base de donnees (70) locale ou 
distante. En outre, la base de donnees comprend les identifiants des differents 

10 fournisseurs de service ENUM (tel que 30), les adresses IP ou les noms de machine 
des DNS tiers 2, des demandes de modification automatique de profil ENUM, les 
historiques de modification manuelle ou automatique de profils ENUM, les adresses 
de notification de modification du profil ENUM (N° de fax, SMS, eMail). 

15 Le systeme comprend encore un module de gestion de protocole DNS (62), de 

preference dans sa forme securis6e (DNSSec). Ce module joue en paruculier le rdle de 
RESOLVER pour la lecture des enregistrements de ressource. 

Le cas echeant, un module de gestion de protocole LDAP (64) y est adjoint pour 
permettre la lecture et la modification d'enregistrements dans un annuaire LDAP. 



20 



25 



Le systeme comprend egalement un module (72) permettant la configuration des 
adresses des serveurs DNS de niveau 2 ainsi qu'un module (71) charge de tenir a jour 
les modifications manuelles ou automatiques des profils ENUM et d'elaborer, le cas 
echeant, des statistiques pour l'exploitant du systeme. 



Les moyens de contrdle sont consumes, d'une part, d'un module (74) charge de 
la configuration automatique de profils ENUM a partir de demandes de modification 
automatique programmes par des abonnes et stockees dans la base de donnees (70) 
et, d'autre part, d'un module (75) charge de la configuration « manuelle » des profils 
30 ENUM. Ce dernier gere des scripts ENUM, notamment un script de lecture de profil 
ENUM (on rappelle qu'un profil ENUM est constitue d'une liste d'enregistrements de 
ressource NAPTR), des scripts de modification des champs des enregistrements de 
ressource NAPTR et notamment des champs ordre, preference, service (adresse eMail, 
numero de telephone, adresse eMail etc.). Si Ton souhaite prevoir la consultation 
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et/ou la mise a jour d'enregistrements de ressource DNS autres que NAPTR, des 
scripts supplementaires doivent etre prevus pour leur modification. 

La Fig. 4 illustre schematiquement une procedure de consultation et de 
5 modification manuelle d'un profil ENUM en mode vocal via un telephone fixe ou 
mobile de type RTC, RNIS, GSM ou IP. 

L'abonne ENUM emet a l'etape 100 un appel telephonique gratuit (type numero 
vert) ou payant selon un mode de remuneration geographique ou forfaitaire de type 
audiotel ou numeros colores depuis un terminal fixe RTC (4) ou RNIS (2) connecte 
10 sur le reseau public ou derriere un PABX (3) ou un terminal mobile (6) de type GSM, 
ou depuis un terminal IP (7) a destination de l'interface RTC/RNIS (51) du systeme 
(50). L'automate de traitement d'appel (52) accepte automatiquement l'appel entrant a 
l'etape 101. Le module script ENUM (75) donne a l'etape 102 l'ordre au module de 
synthese vocale (55) ou au module de diffusion de fichiers vocaux (56) de diffuser a 
1 5 l'etape 103 vers l'abonne ENUM une annonce vocale invitant l'abonne ENUM a saisir 
son numero ENUM E.164 ainsi que son pseudonyme et son mot de passe . L'abonne 
ENUM saisit a l'etape 104 via son clavier ces informations qui sont vehiculees dans la 
bande sous forme de DTMF et qui sont interceptees par le module de traitement des 
DTMF (54). Ces informations sont foumies a l'etape 105 au module d'authentification 
20 (73) qui interroge la base de donnees locale ou distante (via par exemple une interface 
de type ODBC (pour Open DataBase Connectivity)) en operant une recherche sur le 
Numero ENUM E.164. Celle-ci fournit a l'etape 107 les informations 
d'authentification correspondantes au module d'authentification (73). Ce dernier 
compare le pseudonyme et le mot de passe saisis par le client ENUM avec les 
25 informations d'authentification contenues dans la base de donnees (70). En cas de 
concordance, le module d'authentification (73) ordonne a l'etape 108 au module de 
synthese vocale (55) ou au module de diffusion de fichiers vocaux de diffuser a 
l'etape 109 vers l'abonne ENUM une annonce du type "Pour consulter votre profil 
ENUM taper sur la touche 1, pour modifier les attributs de votre profil taper sur 2, 
30 pour configurer de maniere automatique votre profil tapez sur 3, pour modifier votre 
pseudonyme-mot de passe tapez sur 4, pour acceder a votre journal de modification de 
votre profii tapez 5, etc. Si l'abonne ENUM tape sur la touche 1 de son clavier 
telephonique a l'etape 110, le code DTMF correpondant est intercepts par le module 
de traitement des DTMF (54) et est retransmis a l'etape 111 vers le module script 
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ENUM (75). Le script ENUM (75) detecte alors qu'il s'agit d'une commande de 
lecture du profil ENUM. Le script ENUM (75) emet alors a l'etape 1 12 une demande 
d'interrogation au module protocole DNS (62) en fournissant en argument l'adresse 
E.164 de l'abonne ENUM mise sous forme de domaine (transformation du numero de 
5 telephone E.164 de type 33296053859 en (9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module 
de gestion de protocole DNS (62) qui joue le role classique d'un RESOLVER peut 
d'abord verifier si les informations ne sont pas presentes dans son cache suite a une 
consultation precedente ou interroger (a l'etape 1 13) selon le protocole standard DNS 
(requete DNS Query) successivement le serveur DNS de niveau 0, le serveur de DNS 
10 de niveau 1, puis le serveur DNS de niveau 2 par la pile de protocole DNS (32). Pour 
gagner en efficacite, les donnees d'un enregistrement NAPTR sont chargees dans la 
memoire vive du serveur DNS (31). Si l'abonne ENUM est effectivement enregistre 
dans le serveur DNS (31) du fournisseur de service ENUM (30) alors la pile de 
protocole DNS (32) retourne (a l'etape 114) au module protocole DNS (62) la liste 
15 des enregistrements NAPTR correspondents. Le module de protocole DNS (62) se 
charge ensuite de les retransmettre vers le module Script ENUM (75) a l'etape 1 15. Le 
module (75) analyse et interprete les enregistrements NAPTR et genere un texte 
comprehensible par l'abonne ENUM du type "Service N° 1: telephone vers le 
0296053859, service N°2: telephone vers le 0686166924, service N°3: eMail vers 
20 hertrand.dupo nt (2)Td.francetelecom.com . etc.). Ce texte est envoye vers le module de 
synthese vocale (55) a l'etape 116 qui se charge de diffuser cette information a 
l'abonne ENUM a l'etape 1 17. Dans le cas ou le module de diffusion de fichiers 
vocaux (56) est utilise, le module (75) genere l'enchainement des fichiers vocaux a 
jouer. 

25 Apres diffusion de cette information, le module de synthese vocale (55) ou le 

module de diffusion de fichiers vocaux (56) diffuse a nouveau a l'etape 118 la liste 
des operations d'administration possibles sur le profil ENUM "Pour consulter votre 
profil ENUM taper sur la touche 1, pour modifier les attributs de votre profil taper sur 
2, pour configurer de maniere automatique votre profil tapez sur 3, pour modifier 

30 votre pseudonyme-mot de passe, tapez sur 4, pour acceder a votre journal de 
modification de votre profil tapez sur 5, etc.). 

Si l'abonne ENUM choisit la modification de son profil ENUM a l'etape 150, 
cette commande est interceptee par le module script ENUM (75) a l'etape 151, suite a 
la detection du code DTMF par le module de traitement DTMF (54). Le systeme (50) 
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entre alors dans un dialogue iteratif base sur la diffusion de messages vocaux vers 
l'abonne ENUM a partir d'un texte genere par le module script ENUM (75) (a l'etape 
152) en fonction du contexte et diffuses (a l'etape 153) sous forme vocale par le 
module de synthese vocale (55) ou par le module de diffusion de fichiers vocaux 
5 concatenes (56). Ce dernier valide les choix proposes en utilisant son clavier DTMF a 
l'etape 154 et les commandes sont transmises a l'etape 155 vers le script ENUM (75). 
Par exemple, le dialogue vocal peut etre le suivant: 

o -» pour modifier l'ordre/preference de vos services tapez sur 1 , pour modifier 
les attributs d'un service tapez 2, pour ajouter un service tapez 3, pour 
supprimer un service tapez 4,etc. 
o -> 4 

o -> pour supprimer le numero de telephone 0296053859 tapez 1, pour 
supprimer le numero de telephone 0686166924 tapez 2, pour supprimer 
l'adresse eMail hertrand.dupont@rd.fr ancetelecom.com tapez 3, etc. 
o ->2 

o -> Pour valider votre choix tapez 1 , sinon tapez 2 
o -»1 

o -> Pour supprimer un service tapez 1 , pour enregistrer vos modifications tapez 

2, pour revenir au menu principal tapez sur 0 
o ->2 

Lorsque l'abonne ENUM demande la prise en compte des modifications du 
profil ENUM, le module script ENUM (75) emet une requete de demande de 
25 modification a l'etape 156 vers le module protocole DNS (62). Ce dernier emet une 
commande DNS UPDATE a l'etape 157 a destination du module protocole DNS (32) 
du serveur DNS (31) du fournisseur de service ENUM (30). II est rappele que 
l'adresse IP de ce dernier est stockee dans la base de donnees (70) et qu'elle est 
retrouvee a partir du numero E.164 de l'abonne ENUM. Le module protocole DNS 
30 (32) met a jour l'information dans la memoire vive du serveur (31) et demande la mise 
a jour de la base de donnees (33) qui est generalement un fichier texte a plat. Le 
orotocole DNS eere le numero de modification dans ce fichier de maniere a ce que 
le/les DNS secondaire(s) puisse(nt) recharger lui/eux-meme(s) cette modification a 
des intervalles de temps predefinis. La base de donnees (33) confirme la mise a jour a 
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l'etape 159, ce qui se traduit par une reponse a la requite de demande de l'etape 160. 
Le script ENUM (75) intercepte a l'etape 161 le code retour de cette reponse puis 
genere a l'etape 162 le message de confirmation/infirmation de prise en compte de la 
modification. Le module de synthese vocale (55) ou le module de diffusion de fichiers 

5 vocaux diffuse cette information vers l'abonne ENUM a l'etape 163. Ce dernier peut 
alors liberer la communication. 

Selon une variante de cette procedure, en reponse aux messages vocaux, 
l'abonne peut fournir directement une reponse de maniere vocale. C'est alors le 
module de reconnaissance vocale qui determine le choix ou 1' information contenue 

10 dans la reponse. 



La Fig. 5 illustre schematiquement la procedure de consultation et de 
modification manuelle d'un profil ENUM via l'envoi de SMS depuis des terminaux 

1 5 telephoniques mobile ou fixe de type GSM, RTC, RNIS ou IP. L'abonne ENUM emet 
a l'etape 200 un SMS formate (ex: N°E.164 + pseudonyme + mot de passe + requete) 
comme specifie par le fournisseur de service ENUM (30) depuis un terminal fixe RTC 
(4) ou RNIS (2) connecte sur le reseau public ou derriere le PABX (3) ou un terminal 
mobile (6) de type GSM, ou depuis un terminal IP (7), a destination du module SMS 

20 (58) de la presente invention. Ce dernier transmet le SMS a l'etape 201 vers le module 
script ENUM (75). Ces informations sont fournies a l'etape 202 au module 
d'authentification (73) qui interroge a l'etape 203 la base de donnees locale ou distante 
(via une interface ODBC par exemple) en operant une recherche sur le numero 
ENUM E.164. Celle-ci fournit a l'etape 204 les informations correspondantes au 

25 module d'authentification (73) qui se charge de comparer le pseudonyme et le mot de 
passe saisis par le client ENUM dans le SMS avec les informations d'authentification 
contenues dans la base de donnees. En cas de concordance, le module 
d'authentification (73) ordonne a l'etape 205 au module script ENUM (75) de traiter la 
requSte contenue dans le SMS. Le script ENUM (75) detecte qu'il s'agit d'une 

30 commande de lecture du profil ENUM. Par consequent, le script ENUM (75) emet 
une demande d'interrogation a l'etape 206 au module de gestion protocole DNS (62) 
f : * Q.^opt c^roeco P 1 Hp I'aknnnp FN'JM transformee sous 

Qfl [OQlIUSdCUlV Gil OljjllillWlll i uuiv^ov 1_>.*wi »»•»• . — ■ * 

forme de domaine (transformation du numero de telephone E.164 de type 
33296053859 en (9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion protocole 
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DNS (62) qui joue le role classique d'un RESOLVER interroge (etape 207) a l'aide 
d'une requete (DNS Query) le serveur DNS de niveau 0, puis le serveur DNS de 
niveau 1, a moins que les informations ne soient deja dans son cache suite a une 
consultation precedente de ces serveurs. Pour gagner en efficacite, les donnees d'un 
5 serveur DNS sont chargees dans la memoire vive du serveur (3 1 ). Si l'abonne ENUM 
est effectivement enregistre dans le serveur DNS (31) du foumisseur de service 
ENUM (30) alors le module protocole DNS (32) retourne a l'etape 208 les 
enregistrements NAPTR correspondants. Le module de gestion de protocole DNS (62) 
se charge ensuite de les retransmettre vers le module script ENUM (75) a l'etape 209. 
10 Ce dernier analyse et interprete les enregistrements NAPTR et genere un texte 
relativement synthetique et comprehensible par l'abonne ENUM du type "PI: Tel= 
0296053859, P2: Tel=0686 166924, P3: eMail= 

hertrand.dupnntrSrd.francetelecom.com. P4: url=www.bertranddupont.fr, etc.). Ce 
texte est envoye a l'etape 210 vers le module d'envoi de SMS (58) qui envoie le SMS 
15 (a l'etape 211) vers le terminal telephonique a l'origine de la requete (utilisation du 
Numero de l'appelant). 

L'abonne ENUM emet a l'etape 250 un message SMS formate (ex: N° E.164 + 
pseudonyme + mot de passe + type de requete= ECR: PI :tel=0686 166924, 
P2:email=bertrand.dupont@rd.francetelecom.com) comme specifie par le foumisseur 
20 de service ENUM (30) depuis un terminal fixe RTC (4) ou RNIS (2) connecte sur le 
reseau public ou derriere le PABX (3) ou un terminal mobile (6) de type GSM, ou 
depuis un terminal IP (7) a destination du module SMS (58) de la presente invention. 
Ce dernier transmet le message SMS a l'etape 25 1 vers le module script ENUM (75). 
Ces informations sont foumies a l'etape 252 au module d'authentification (73) qui 
25 interroge a l'etape 253 la base de donnees locale ou distante (via une interface ODBC 
par exemple) en operant une recherche sur le numero ENUM E. 164. Celle-ci fournit a 
l'etape 254 les informations correspondantes au module d'authentification (73) qui se 
charge de comparer le pseudonyme et le mot de passe saisis par le client ENUM dans 
le message SMS avec les informations d'authentification contenues dans la base de 
30 donnees. En cas de concordance, le module d'authentification (73) en avertit le module 
script ENUM (75) qui traite alors la requete contenue dans le SMS. Le script ENUM 
(75) detecte qu'il s'agii d'une commande de mise a jour du profil ENUM avec des 
arguments. Le script ENUM (75) verifie la syntaxe de la commande et, si elle est 
correcte, emet une demande de mise a jour a l'etape 256 au module de gestion de 
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protocole DNS (62). Ce dernier emet une commande DNS UPDATE a l'etape 257 a 
destination du module protocole DNS (32) du serveur DNS (31) du foumisseur de 
service ENUM (30). II est rappele que l'adresse IP de ce dernier est stockee dans la 
base de donnees (70) et qu'elle est retrouvee a partir du numero E.164 de l'abonne 

5 ENUM. Le module protocole DNS (32) met a jour l'information dans la memoire vive 
du serveur (31) et demande la mise a jour de la base de donnees (33) qui est 
generalement un fichier texte a plat. Le protocole DNS gere le numero de 
modification dans ce fichier de maniere a ce que le/les serveur(s) DNS secondaire(s) 
puisse(nt) recharger lui/eux-meme(s) cette modification a des intervalles de temps 

10 predefinis. Le serveur (31) confirme la mise a jour a l'etape 259, ce qui se traduit par 
une reponse a la requete de demande de mise a jour a l'etape 260. Le script ENUM 
(75) intercepte a l'etape 261 le code retour de cette reponse puis genere a l'etape 262 
le message de confirmation/infirmation de prise en compte de la modification avant de 
l'envoyer au module d'envoi de SMS (58) qui se charge d'envoyer le SMS a l'etape 

15 263 vers le terminal telephonique a l'origine de la requete (utilisation du numero de 
l'appelant). 

La Fig. 6 illustre schematiquement la procedure de consultation et de 
modification manuelle d'un profil ENUM par le web a partir d'un terminal disposant 

20 d'un navigateur web (8). 

L'abonne ENUM demande a l'etape 300 le telechargement de la page web 
d'accueil du service de gestion du profil ENUM. Celle-ci est retournee a l'etape 301 
par le serveur web (63) de la presente invention. Cette page web affiche un formulaire 
d'authentification a l'abonne ENUM. Celui ci saisit son numero E.164 puis son 

25 pseudonyme et son mot de passe. Ces informations sont transmises a l'etape 302 au 
serveur web (63) qui lui meme les transmet a l'etape 303 au module d'authentification 
(73). Le module d'authentification (73) interroge a l'etape 304 la base de donnees 
locale ou distante (via une interface ODBC par exemple) en operant une recherche sur 
le numero ENUM E.164. Celle-ci fournit a l'etape 305 les informations 

30 correspondantes au module d'authentification (73) qui se charge de comparer le 
pseudonyme et le mot de passe saisis par le client ENUM dans le formulaire web et 

la base de donnees. En cas de 

ICS 1A1XVJ11HCIL1VU12» \M C*V»v*aw**v**.**.»*w V *- — — — — 

concordance, le module d'authentification (73) notifie a l'etape 306 le module serveur 
web (63) que l'authentification est reussie. Celui-ci emet a l'6tape 307, a destination 
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du module script ENUM (75), une requ6te de lecture du profil ENUM. Par 
consequent, le script ENUM (75) emet une demande ^interrogation a l'etape 308 au 
module protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonne 
ENUM transformee sous forme de domaine (transformation du numero de telephone 

5 E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module protocole 
DNS (62) qui joue le r61e classique d'un RESOLVER interroge (a l'etape 309) apres 
avoir verifie si les informations ne sont pas presentes dans son cache suite a une 
consultation precedents a l'aide du protocole standard DNS (requete DNS Query) 
successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le 

10 serveur DNS de niveau 2. Pour gagner en efficacite, les donnees d'un DNS sont 
chargees dans la memoire vive du serveur DNS (31). Si l'abonne ENUM est 
effectivement enregistre dans le DNS (31) du fournisseur de service ENUM (30), le 
module protocole DNS (32) retourne a l'etape 310 les enregistrements NAPTR 
correspondants au module protocole DNS (62). Ce dernier les retransmet vers le 

1 5 module script ENUM (75) a l'6tape 3 1 1 qui interprete les enregistrements NAPTR et 
genere un texte relativement synthetique et comprehensible par l'abonne ENUM du 
type: 

Service de priorite 1 Tel: 0296053859 

20 Service de priorite 2 Tel: 0686166924 

Service de priorite 3 Mail: b.dupont(5),rd.ft.com 

Service de priorite 4 Web : www.bertranddupont.fr, 

Ce texte est envoye a l'etape 312 vers le module serveur web (63) qui telecharge une 
25 page web munie de ces informations a l'etape 313 vers le terminal Web (8) de 
l'abonne ENUM. 

La page web presentee a l'abonne ENUM permet via une interface graphique 
adaptee d'operer des modifications de profil ENUM courant: modification des 
30 priorites, ajout de service, suppression de service, modification des attributs d'un 
service, etc. La demande en modification est emise a l'etape 350 a destination du 
serveur web (63). Ce dernier transmet a l'etape 351 la requete vers le module script 
ENUM (75) qui se charge de formater la requete conformement aux entrees NAPTR 
decrites par le protocole ENUM. Le script ENUM (75) emet alors une demande de 
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mise a jour a l'etape 352 au module protocole DNS (62). Ce dernier emet une 
commande DNS UPDATE a l'etape 353 a destination du module protocole DNS (32) 
du serveur DNS (31) du fournisseur de service ENUM (30). II est rappete que 
l'adresse IP de ce dernier est stockee dans la base de donnees (70) et qu'elle est 
5 retrouvee a partir du numero E.164 de l'abonne ENUM. Le module protocole DNS 
(32) met a jour l'information dans la memoire vive du serveur (31) et demande la mise 
a jour de la base de donnees (33) qui est generalement un fichier texte a plat. Le 
protocole DNS gere le numero de modification dans ce fichier de maniere a ce que 
le/les serveur(s) DNS secondaire(s) puisse(nt) recharger lui/eux-meme(s) cette 

10 modification a des intervalles de temps predefinis. La base de donnees (33) confirme 
la mise a jour a l'etape 355, ce qui se traduit par une r6ponse a la requete de demande 
de mise a jour a l'6tape 356. Le script ENUM (75) intercepte a l'etape 357 le code 
retour de cette reponse puis genere a l'etape 358 le message de 
confirmation/infirmation de prise en compte de la modification avant de l'envoyer au 

15 serveur web (63) qui se charge de formater la page web de resultat avant de la 
telecharger a l'etape 359 vers le terminal web (8). 

La Fig. 7 illustre schematiquement la procedure de consultation et de 
modification manuelle d'un profil ENUM a partir d'un Minitel. 

20 L'abonne ENUM se connecte au service Minitel en utilisant la fonction PAVI 

(Point d'Acces Videotex) du reseau de France Telecom (appel par exemple du 3615 
code ENUM-FT). Le terminal minitel (5) entre alors en session avec le serveur minitel 
(57) a l'etape 400. Ce dernier active a l'etape 401 le module script ENUM (75) de la 
presente invention qui genere alors la page d'accueil du service a l'etape 402 et qui est 

25 telechargee a l'etape 403 sur le terminal Minitel (5) de l'abonne ENUM . Cette page 
Minitel affiche un formulaire d'authentification a l'abonne ENUM. Celui-ci saisit son 
numero ENUM E.164 puis son pseudonyme et son mot de passe. Ces informations 
sont transmises a l'etape 404 au serveur Minitel (57) qui lui meme les transmet a 
l'etape 405 au module script ENUM (75). Ce dernier redirige la requete a l'etape 406 

30 vers le module d'authentification (73). Le module d'authentification (73) interroge a 
l'etape 407 la base de donnees locale ou distante (via une interface ODBC par 
exemple) en operant une recherche sur le numero ENUM E.164. A l'etape 408 les 
informations d'authentification de la base de donnees sont transmises au module 
d'authentification (73) qui les compare avec le pseudonyme et le mot de passe saisis 
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dans le formulaire Minitel. En cas de concordance, le module d' authentication (73) 
notifie a l'etape 409 le module script ENUM (75) que l'authentification est reussie. Le 
module script ENUM (75) emet alors une demande d'interrogation a l'etape 410 au 
module protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonne 

5 ENUM transformee sous forme de domaine (transformation du numero de telephone 
E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module protocole 
DNS (62) qui joue le role classique d'un RESOLVER interroge (etape 411), apres 
avoir verifie si les informations ne sont pas presentes dans son cache suite a une 
consultation precedente, a l'aide du protocole standard DNS (requete DNS Query) 

10 successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le 
serveur DNS de niveau 2. De preference, pour gagner en efficacite, les donnees d'un 
DNS sont chargees dans la memoire vive du serveur DNS (31). Si l'abonne ENUM est 
effectivement enregistre dans le serveur DNS (31) du fournisseur de service ENUM 
(30), le module protocole DNS (32) retourne (a l'etape 412) les enregistrements 

15 NAPTR correspondents. Le module de protocole DNS (62) se charge de les 
retransmettre vers le module script ENUM (75) a l'etape 413. Ce dernier analyse et 
interprete les enregistrements NAPTR et genere un texte relativement synthetique et 
comprehensible par l'abonne ENUM du type: 

20 Service de priorite 1 Tel: 0296053859 

Service de priorite 2 Tel: 06861 66924 

Service de priorite 3 Mail: b.dupont(S),rd.ft.com 

Service de priorite 4 Web www.bertranddupont.fr, 

25 Ce texte est envoye a l'etape 414 vers le module serveur videotex (57) qui se charge 
de telecharger a l'etape 415 vers le terminal Minitel (5) de l'abonne ENUM . 

La page videotex presentee a l'abonne ENUM permet via une interface adaptee 
d'operer des modifications sur le profil ENUM courant: modification des priorites, 
30 ajout de service, suppression de service, modification des attribute d'un service, etc. La 
requete de mise a jour du profil ENUM est emise a l'etape 450 a destination du 
serveur videotex (57). Ce demier transmet a l'etape 451 la requete vers le module 
script ENUM (75) qui se charge de formater la requete conformement aux entrees 
NAPTR decrites par le protocole ENUM. Le script ENUM (75) emet alors une 
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demande de mise a jour a l'etape 452 au module protocole DNS (62). Ce dernier emet 
une commande DNS UPDATE a l'etape 453 a destination du module protocole DNS 
(32) du serveur DNS (31) du fournisseur de service ENUM (30). II est rappele que 
1'adresse IP de ce dernier est stockee dans la base de donnees (70) et qu'elle est 

5 retrouvee a partir du numero E.164 de l'abonne ENUM. Le module protocole DNS 
(32) met a jour l'information dans la memoire vive du serveur (31) et demande la mise 
a jour de la base de donnees (33) qui est generalement un fichier texte a plat. Le 
protocole DNS gere le numero de modification dans ce fichier de maniere a ce que 
le/les serveurs DNS secondaire(s) puisse(nt) recharger lui/eux-meme(s) cette 

10 modification a des intervalles de temps predefinis. La base de donnees (33) confirme 
la mise a jour a l'etape 455, ce qui se traduit par une reponse a la requete de demande 
de mise a jour a l'etape 456. Le script ENUM (75) intercepte a l'etape 457 le code 
retour de cette reponse puis genere a l'etape 458 le message de 
confirmation/infirmation de prise en compte de la modification avant de l'envoyer au 

1 5 serveur videotex (57) qui se charge de formater la page videotex de resultat avant de 
la telecharger a l'etape 459 vers le terminal Minitel (5). 

La Fig. 8 illustre schematiquement la procedure de consultation et de 
modification manuelle d'un profil ENUM par eMail a partir d'un terminal disposant 

20 d'un client eMail (8). 

L'abonne ENUM emet un eMail formate a l'etape 500 a destination du serveur 
eMail (61). La commande ENUM est par exemple passee dans 1'adresse eMail 
destinataire: 



25 el 64-33296053859-login-dupont-password-1234-requete 
lire@gestion.enum.francetelecom.com 

Le module script ENUM (75) dispose d'un client eMail qui vient regulierement 
scruter le serveur eMail (61). Lorsque le module script ENUM (75) recoit a l'etape 
30 501 un eMail comme indique ci-dessus, il recupere, soit dans l'entete, soit dans le 
corps de 1'eMail, les arguments fournis puis les transmet a l'etape 502 vers le module 
d'authentification (73). Le module d'authentification (73) interroge a l'etape 503 la 
base de donnees locale ou distante (via une interface ODBC par exemple) en 
effectuant une recherche sur le numero ENUM E.164. Celle-ci foumit a l'etape 504 
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les informations d'authentification correspondantes au module d'authentification (73) 
qui les compare au pseudonyme (login_id) et au mot de passe (password) foumis par 
le client ENUM dans 1'eMail. En cas de concordance, le module d'authentification 
(73) en avertit le module script ENUM (75) a l'etape 505. Par consequent, le script 

5 ENUM (75) emet une demande d'interrogation a l'etape 506 au module de gestion de 
protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonne ENUM 
transformee en nom de domaine (transformation du numero de telephone E.164 de 
type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de 
protocole DNS (62) qui joue le role classique d'un RESOLVER interroge (etape 507), 

10 si toutefois les informations ne sont pas deja presentes dans son cache suite a une 
consultation precedente, selon le protocole standard DNS (requete DNS Query) 
successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le 
serveur DNS de niveau 2 par la pile de protocole DNS (32). De preference, pour 
gagner en efficacite, les donnees d'un DNS sont chargees dans la memoire vive du 

15 serveur DNS (31). Si l'abonne ENUM est effectivement enregistre dans le DNS (31) 
du foumisseur de service ENUM (30) alors le module de gestion de protocole DNS 
(32) retourne a l'etape 508 les enregistrements NAPTR correspondants. Le module de 
gestion de protocole DNS (62) se charge de les retransmettre vers le module script 
ENUM (75) a l'etape 509. Ce dernier analyse et interprete les enregistrements 

20 NAPTR et genere un texte relativement synthetique et comprehensible par l'abonn6 
ENUM du type: 

Service de priorite 1 Tel: 0296053859 

Service de priorite 2 Tel: 0686166924 

25 Service de priorite 3 Mail: b.dupont(%d.ft.com 

Service de priorite 4 Web www.bertranddupont.fr, 

Ce texte est expedie (etape 510) sous forme d'eMail par le logiciel client eMail 
integre dans le module script ENUM vers le module serveur eMail (61) qui se charge 
30 de l'envoyer vers l'abonne ENUM. 

L'abonne ENUM qui souhaite modifier son Profil ENUM envoie un eMail 
formate a l'etape 550 a destination du serveur eMail (61). La commande ENUM est 
par exemple passee dans l'adresse eMail destinataire, par exemple: 
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e 164-33296053859-login-dupont-password-1234-requete-ecrire-Pl-tel-0296053859- 
P2-tel-0686166924-P3-fax-0296050242@gestion.enum.francetelecom.com 

Le client eMail du module script ENUM scrute le serveur eMail (61). Lorsque le 

5 module script ENUM recoit (en 551) un eMail comme indique ci-dessus, il recupere, 
soit dans l'entete, soit dans le corps de 1'eMail, les arguments fournis puis les transmet 
a l'etape 552 vers le module d'authentification (73). Le module d'authentification (73) 
interroge a l'etape 553 la base de donnees locale ou distante (via une interface ODBC 
par exemple) en operant une recherche sur le numero ENUM E.164. Celle-ci fournit a 

10 l'etape 554 les informations d'authentification correspondantes et le module 
d'authentification (73) les compare au pseudonyme et au mot de passe fournis dans 
1'eMail. En cas de concordance, le module d'authentification (73) en avertit le module 
script ENUM (75) a l'etape 555. Ce dernier formate la requete conformement aux 
entrees NAPTR decrites par le protocole ENUM. Le script ENUM (75) transmet alors 

15 une demande de mise a jour a l'etape 556 au module de gestion de protocole DNS 
(62) qui emet une commande DNS UPDATE a l'etape 557 a destination du module 
protocole DNS (32) du serveur DNS (31) du fournisseur de service ENUM (30). II est 
rappele que l'adresse IP de ce dernier est stockee dans la base de donnees (70) et 
qu'elle est retrouvee a partir du numero E.164 de l'abonne ENUM. Le module 

20 protocole DNS (32) met a jour l'information dans la memoire vive du serveur (31) et 
demande la mise a jour de la base de donnees (33) qui est generalement un fichier 
texte a plat. Le protocole DNS gere le numero de modification dans ce fichier de 
maniere a ce que le/les serveur(s) DNS secondaire(s) puisse(nt) recharger lui/eux- 
meme(s) cette modification a des intervalles de temps predefinis. La base de donnees 

25 (33) confirme la mise a jour a l'etape 559, ce qui se traduit par une reponse a la 
requete de demande de mise a jour a l'etape 560. Le module script ENUM (75) 
intercepte a l'etape 561 le code retour de cette reponse puis genere le message de 
confirmation/infirmation de prise en compte de la modification. Ce message est 
expedie (a l'etape 562) sous forme d'eMail par le logiciel client integre dans le 

30 module script ENUM au serveur eMail (61). Ce dernier envoie a l'etape 563 1'eMail 
en question a l'abonne ENUM qui peut le consulter sur son terminal (8). 
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La Fig. 9 illustre sctoSmatiquement la procedure de consultation et de 
modification manuelle d'un profil ENUM par IUU (Information d'Usager a Usager) a 
partir d'un terminal RNIS (2). 

L'abonne ENUM emet a l'etape 600 depuis son terminal RNIS (2) un appel 
5 telephonique contenant l'el&nent d'information IUU vers l'interface RNIS (51). II faut 
rappeler que le champ IUU est actuellement limite a une taille de 32 caracteres. La 
commande ENUM qui est inseree dans le champ IUU ne pourra done agir que sur un 
service ENUM a la fois. Par exemple: GetPl-33296053859*dupont#123456: cette 
requSte permet de r6cup6rer les attributs du service ENUM de priority 1 . 
10 L'automate d'appel (52) transmet a l'etape 601 le message de demande 

d'etablissement d'appel au module IUU (53) qui va extraire la commande IUU. 
L'automate d'appel (52) emet a l'ftape 652 le message Alerte a destination de l'abonne 
ENUM de mantere a s'autoriser un minimum de temps (temporisation du protocole 
RNIS avant d'envoyer un message de ddconnexion). Le module IUU (53) transmet la 
15 commande ENUM a l'etape 603 vers le module script ENUM (75). Ce dernier 
recupere les arguments ENUM fournis puis les transmet a l'etape 604 vers le module 
d'authentification (73). Le module d'authentification (73) interroge a l'etape 605 la 
base de donnSes locale ou distante (via une interface ODBC par exemple) en operant 
une recherche sur le numero ENUM E.164. Celle-ci foumit a l'etape 606 les 
20 informations d'authentification correspondantes au module d'authentification (73) qui 
les compare avec le pseudonyme et le mot de passe fournis par le client ENUM dans 
TIUU. En cas de concordance, le module d'authentification (73) en avertit le module 
script ENUM (75) a l'etape 607. Par suite, le module script ENUM (75) emet une 
demande d'interrogation a l'etape 608 au module de gestion de protocole DNS (62) en 
25 fournissant en argument l'adresse E.164 de l'abonne ENUM transformee sous forme 
de domaine (transformation du numero de telephone E.164 de type 33296053859 en 
9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui joue 
le rdle classique d'un RESOLVER peut interroger (a l'etape 609), apres avoir verifie si 
les informations ne sont pas deja dans son cache suite a une consultation pr6c6dente, a 
30 l'aide du protocole standard DNS (requete DNS Query) le DNS niveau 0 puis le DNS 
niveau 1, puis le DNS niveau 2 via son module de protocole DNS (32). De 
preference, pour gagner en efficacite, les donnees d'un serveur DNS sont chargees 
dans la memoire vive du serveur (3 1). Si l'abonne ENUM est effectivement enregistre 
dans le DNS (3 1) du fournisseur de service ENUM (30), la pile de protocole DNS (32) 



WO 03/107627 PCT/FR03/01691 

27 



retourne a l'etape 610 les enregistrements NAPTR correspondents au module de 
gestion protocole DNS (62) qui se charge de les retransmettre vers le module script 
ENUM (75) a l'etape 611. Ce dernier analyse et interprete les enregistrements 
NAPTR et en fonction du service demande dans la commande IUU genere un texte 
5 relativement synthetique et comprehensible par l'abonne ENUM du type: 

Service PI: Tel:0296053859 



10 



Ce texte est envoye a l'etape 612 vers le module IUU (53) qui se charge de 
formater un message de deconnexion avant de l'envoyer a l'etape 613 au module 
automate d'appel (52). Ce dernier genere le message de deconnexion RNIS qui 
contient l'element d'information KJU et qui est done transmis a l'etape 614 via le 
reseau RNIS au terminal (2) de l'abonne ENUM. Ce dernier peut visualiser 1'IUU sur 
l'afficheur de son terminal RNIS (2). 
15 L'abonne ENUM qui souhaite modifier son profil ENUM emet a l'etape 650 

depuis son terminal RNIS (2) un appel telephonique contenant l'element d'information 
IUU vers l'interface RNIS (51). Par exemple: DelP3-33296053859*dupont#123456: 
cette requSte permet de supprimer le service ENUM de priorite 3. 

L'automate d'appel (52) transmet a l'etape 651 un message de demande 
20 d'etablissement d'appel au module IUU (53) qui extrait la commande RJU. L'automate 
d'appel (52) emet a l'etape 652 le message Alerte a destination de l'abonne ENUM de 
maniere a s'autoriser un minimum de temps (temporisation du protocole RNIS avant 
d'envoyer un message de deconnexion). Le module IUU (53) transmet la commande 
ENUM a l'etape 653 vers le module script ENUM (75). Ce dernier recupere les 
25 arguments fournis puis les transmet a l'etape 654 vers le module d'authentification 
(73). Le module d'authentification (73) interroge a l'etape 655 la base de donnees 
locale ou distante (via une interface ODBC par exemple) en operant une recherche sur 
le numero ENUM E.164. Celle-ci foumit a l'etape 656 les informations 
d'authentification correspondantes au module d'authentification (73) qui les compare 
30 au pseudonyme et au mot de passe fournis par le client ENUM dans 1'IUU. En cas de 
concordance, le module d'authentification (73) en avertit le module script ENUM (75) 
a l'etape 657. Etant donne que la modification ne porte pas sur Pensemble du profil, le 
script ENUM (75) emet d'abord une demande d'interrogation (a l'etape 658) au 
module de gestion de protocole DNS (62) en fournissant en argument l'adresse E.164 
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de l'abonne ENUM transformee sous forme de domaine (transformation du numero de 
telephone E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module 
de gestion de protocole DNS (62), qui joue le r61e de RESOLVER, peut interroger (a 
l'etape 659), apres avoir verifie si les informations ne sont pas deja dans son cache 

5 suite a une consultation prec^dente, a l'aide du protocole standard DNS (requete DNS 
Query) le DNS niveau 0, le DNS niveau 1 puis le DNS niveau 2 via son module de 
protocole DNS (32). Pour gagner en efficacite, les donnees d'un DNS sont chargees 
dans la memoire vive du serveur (31). Si l'abonne ENUM est effectivement enregistre 
dans le DNS (31) du foumisseur de service ENUM (30), le module protocole DNS 

10 (32) retourne a l'6tape 660 les enregistrements NAPTR correspondants au module de 
gestion de protocole DNS (62). Ce dernier se charge de les retransmettre vers le 
module script ENUM (75) a l'etape 661. Le script ENUM (75) emet alors une 
demande de mise a jour en tenant compte de la modification demandee dans le champ 
IUU a l'etape 662 au module protocole DNS (62). Ce dernier emet une commande 

15 DNS UPDATE a l'etape 663 k destination du module protocole DNS (32) du serveur 
DNS (31) du foumisseur de service ENUM (30). II est rappele que l'adresse IP de ce 
dernier est stockee dans la base de donnees (70) et qu'elle est retrouvee a partir du 
numero E.164 de l'abonnS ENUM. Le module protocole DNS (32) met a jour 
l'information dans la memoire vive du serveur (31) et demande la mise a jour de la 

20 base de donnees (33) qui est generalement un fichier texte a plat. Le protocole DNS 
gere le numero de modification dans ce fichier de maniere a ce que le/les serveurs 
DNS secondaire(s) puisse(nt) recharger lui/eux-meme(s) cette modification k des 
intervalles de temps predefinis. La base de donnees (33) confirme la mise a jour a 
l'etape 665, ce qui se traduit par une reponse k la requite de demande de mise k jour a 

25 l'etape 666. Le script ENUM (75) intercepte a l'etape 667 le code retour de cette 
reponse puis genere a l'etape 668 le message de confirmation/infirmation de prise en 
compte de la modification. Ce message est envoys a l'etape 668 vers le module IUU 
(53) qui se charge de formater un message de deconnexion avant de l'envoyer a l'etape 
669 au module automate d'appel (52). Ce dernier genere a l'etape 670 le message de 

30 deconnexion RNIS qui contient l'element d'information IUU et qui est done transmis 
via le reseau RNIS vers le terminal (2) de l'abonne ENUM. Ce dernier peut visualiser 
1'IUU sur I'afJicheur de son terminal RNIS (2). 
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La Fig. 10 illustre schdmatiquement la procedure d'acces au service de 
consultation et de modification automatique d'un profil ENUM a partir d'une session 
web. La tache consistant a modifier manuellement un profil ENUM peut vite devenir 
delicate et repetitive. Un automate (dit automate de configuration) est alors utilise 

5 pour effectuer une modification automatique du profil ENUM en fonction du temps 
et/ou d'autres parametres. Parmi ces autres parametres, la localisation de l'abonne 
peut etre retenue si elle est connue du systeme (50). 

L'abonne ENUM demande a l'etape 700 le telechargement de la page web 
d'accueil du service de gestion du profil ENUM. Celle-ci est retournee a l'etape 701 

10 par le serveur web (63) de la presente invention. Cette page web affiche un formulaire 
d'authentification a l'abonne ENUM. Celui-ci saisit son numero ENUM E.164 puis 
son login et mot de passe. Ces informations sont transmises a l'etape 702 au serveur 
web (63) qui lui meme les transmet (a l'etape 703) au module d'authentification (73). 
Le module d'authentification (73) interroge (a l'etape 704) la base de donnees locale 

15 ou distante (70) (via une interface ODBC par exemple) en operant une recherche sur 
le numero ENUM E.164. Celle-ci foumit a l'etape 705 les informations 
d'authentification correspondantes au module d'authentification (73) qui les compare 
avec le pseudonyme et le mot de passe saisis par le client ENUM dans le formulaire 
web. En cas de concordance, le module d'authentification (73) notifie a l'etape 706 le 

20 module serveur web (63) que l'authentification est nSussie. Celui-ci emet a l'etape 707 
a destination du module script ENUM (75) une requite en lecture de la configuration 
automatique pour ce profil ENUM. Le module script ENUM (75) interroge a l'etape 
708 la base de donnees (70) en fournissant en arguments le numero E.164 de l'abonne 
ENUM. La base de donnees (70) retourne a l'etape 709 le programme de gestion 

25 automatique du profil au module script ENUM(75). Ce dernier met en forme les 
informations, par exemple: 

Lundi au Vendredi: de 08:30 a 19:00 
PI Tel 0296053859 
30 P2 Tel 0686166924 

P3 eMail bertrand.dupont@rd.francetelecom.com 
P4 fax 0296050242 



Lundi au Vendredi: de 19:00 a 08:30 
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PI Tel 0296916404 

P2 eMail bertrand.dupont@rd.francetelecom.com 

Samedi et Dimanche: de 00:00 a 23:59 
5 PI Tel 0296916404 
P2 Tel 0686166924 
P3 eMail b.dupont@wanadoo.fr 

Le module script ENUM (75) transmet les informations formattes a Tetape 710 
10 au serveur web (63) qui se charge de telecharger la page web contenant les 
informations en clair du programme de configuration du profil ENUM sur le terminal 
web (8) de l'abonne ENUM. 

Cette page web permet la modification du programme de configuration 
automatique du profil ENUM: modification des horaires, gestion des jours fertes, 
15 aj out-suppression de service, modifications des attributs des services, etc. L'abonne 
ENUM valide la modification du programme k Tetape 750. Le serveur Web (63) 
transmet ces informations k Tetape 751 vers le module script ENUM (75). Ce dernier 
extrait les informations, les met en forme selon un format dSfini avant de les Scrire 
dans la base de donnees (70), a Tetape 752. Celle-ci prend en compte I'enregistrement 
20 du programme et le confirme a Tetape 753 au module script ENUM (75). Ce dernier 
notifie au serveur web (63) a Tetape 754 la prise en compte de la modification de 
l'automate de configuration du profil ENUM. Le serveur tetecharge k Tetape 755 la 
page web de confirmation de la modification sur le terminal web (8) de l'abonng 
ENUM. 

25 

La Fig. 1 1 illustre la procedure de mise a jour automatique par l'automate de 
configuration des profils ENUM ainsi que la procedure optionnelle de notification de 
changement de profil vers l'abonne ENUM. 

L'automate de configuration (74) scrute regulierement a Tetape 800 la base de 
30 donnees (70) pour verifier s'il y a une modification programmee k realiser (en fonction 
du jour et de l'heure courants). Si une modification est programmee alors les 
paramStres de configuration sont retoumes a Tetape 80!. L'automate de configuration 
(74) 6met une demande d'interrogation k Tetape 802 au module de gestion de 
protocole DNS (62) en fournissant en argument l'adresse E.164 de Pabonn6 ENUM 
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dont le profil est a modifier, transformee sous forme de nom de domaine 
(transformation du numero de telephone E.164 de type 33296053859 en 
9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui 
joue le role d'un RESOLVER peut interroger (a l'etape 803), si toutefois les 
5 informations ne sont pas d6ja dans son cache suite a une consultation precedente, k 
l'aide du protocole standard DNS (requete DNS Query), le serveur DNS niveau 0, le 
serveur DNS niveau 1, puis le serveur DNS niveau 2 via son module de protocole 
DNS (32). De preference, pour gagner en efficacite, les donnees d'un DNS sont 
chargees dans la memoire vive du serveur DNS (31). Si Tabonne ENUM est 

10 effectivement enregistre dans le DNS (3 1) du fournisseur de service ENUM (30) alors 
le module protocole DNS (32) retourne a l'etape 804 les enregistrements NAPTR 
correspondants au module protocole DNS (62). Ce dernier les retransmet vers 
Pautomate de configuration (74) qui consulte alors (etape 806) la base de donnees 
(70) afin de recup&xr les modifications a operer stir le profil ENUM. La base de 

15 donnees retourne (etape 807) le profil a appliquer au module automate de 
configuration (74). Si une modification est effectivement n£cessaire (le profil a pu 
entre temps etre modify manuellement), l'automate de configuration determine les 
modifications a apporter aux enregistrements NAPTR et emet une demande de mise k 
jour a l'etape 808 au module de gestion de protocole DNS (62). Ce dernier emet une 

20 commande DNS UPDATE k l'etape 809 a destination du module protocole DNS (32) 
du serveur DNS (31) du fournisseur de service ENUM (30). II est rappele que 
l'adresse IP de ce dernier est stockee dans la base de donnees (70) et quelle est 
retrouvee a partir du numero E.164 de l'abonn6 ENUM. Le module protocole DNS 
(32) met a jour l'information dans la memoire vive du serveur (31) et demande la mise 

25 k jour de la base de donn6es (33) qui est gen^ralement un fichier texte a plat. Le 
protocole DNS gere le numero de modification dans ce fichier de maniere a ce que 
le/les serveurs DNS secondaire(s) puisse(nt) recharger lui/eux -meme(s) cette 
modification a des intervalles de temps pr&tefmis. La base de donnees (33) confirme 
la mise k jour a l'etape 81 1, ce qui se traduit par une r^ponse a la requete de demande 

30 de mise a jour a l'etape 812. Le module automate de configuration (74) intercepte k 
l'6tape 813 le code retour de cette rSponse puis gen^re k l'6tape 814 une demande 
d'£criture dans la base de donnees (70) pour alimenter le journal des modifications. La 
base de donnees (70) confirme l^criture de Tenement de modification automatique 
du profil a l'etape 815. 
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Si le service de mise a jour automatique a et€ configure pour notifier les 
modifications automatiques de profil ENUM, V automate de configuration notifie la 
mise a jour selon un ou plusieurs des modes suivants : 

5 o dans le cas ou la notification est en mode vocal, l'automate de configuration 

(74) notifie l'automate d'appel (52) a I'etape 820, ce qui se traduit par un 
appel telephonique vers un telephone fixe RTC (4), ou RNIS (2), ou IP (7) ou 
vers un telephone mobile (6). Les informations et adresses de notification 
sont stockees dans la base de donnees (70). L'abonne ENUM rSpond a cet 

10 appel telephonique k I'etape 822 ou l'appel est aiguille vers sa messagerie 

vocale. Le module de synthase vocale (55) ou le module de diffusion de 
fichiers vocaux (56) diffuse k I'etape 823 la notification de la modification de 
profil ENUM, par exemple: "bonjour, votre profil ENUM 33296053859 a 6t6 
mis k jour aujourd'hui k 19:00 comme suit: service telephonique vers 

15 0296053859 puis service telephonique vers 0686166924 puis service eMail 

vers bertrand.dupont@wanadoo.fr " ; 

o dans le cas ou la notification est en mode SMS, l'automate de configuration 
(74) avertit le module SMS (58) k I'etape 830 en fournissant le texte du SMS 
20 par exemple du type: "Modification de votre profil ENUM 33296053859 le 

21/03/2002 k 09:00: t&:0296053859, tel:0686166924,fax:0296050242". Le 
module SMS (58) transmet k I'etape 840 ce message SMS a destination du 
terminal telephonique mobile ou fixe, tel que configure dans la base de 
donnees (70) ; 

25 

o dans le cas ou la notification est en mode eMail, l'automate de configuration 
(74) notifie la mise k jour au serveur eMail (61) (etape 850) k l'aide d'un 
eMail contenant un texte du type: "Modification de votre profil ENUM 
33296053859 le 21/03/2002 a 09:00: tel:0296053859, tel:0686166924, 
30 fax:0296050242". A cette fin, l'automate de configuration dispose d'un client 

eMail. Le serveur eMail (61) transmet ensuite a I'etape 860 1'eMail en 
question a 1'adresse eMail stockSe dans la base de donnees (70) ; 
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o dans le cas ou la notification est en mode fax, l'automate de configuration 
(74) notifie au module fax (59) a l'etape 870 en fournissant le texte du fax qui 
pourrait etre de type: "Modification de votre profil ENUM 33296053859 le 
21/03/2002 a 09:00: tel:0296053859, tel:0686166924,fax:0296050242". Le 
5 module fax (59) transmet a l'etape 880 ce fax a destination du terminal fax 

(9) configure dans la base de donnees (70). 

La Fig. 12 illustre un exemple de procedure de consultation de profil ENUM 
lorsque ce dernier est stocke dans un annuaire LDAP. L'exemple donne en Fig. 12 

10 illustre une consultation via un ordinateur individuel mais il est clair que la 
consultation peut etre realisee au moyen des autres types de terminaux precedemment 
envisages. Ce type de service pourrait notamment etre propose par des entreprises qui 
souhaiteraient offrir I'acces a un service ENUM a toute ou partie de leurs employes. 
L'abonne ENUM demande a l'etape 900 le telechargement de la page web 

15 d'accueil du service de gestion du profil ENUM. Celle-ci est retournee a l'etape 901 
par le serveur web (63) du systeme (50). Cette page web affiche un formulaire 
d'authentification a l'abonne ENUM. Celui-ci saisit son numero ENUM E.164 puis 
son pseudonyme et son mot de passe. Ces informations sont transmises a l'etape 902 
au serveur web (63) qui lui meme les transmet (etape 903) au module 

20 d'authentification (73). Le module d'authentification (73) interroge (etape 904) la base 
de donnees locale ou distante (via une interface ODBC par exemple) en operant une 
recherche sur le numero ENUM E.164. Celle-ci fournit a l'etape 905 les informations 
d'authentification correspondantes au module d'authentification (73) qui se charge de 
les comparer avec le pseudonyme et mot de passe saisis par le client ENUM. En cas 

25 de concordance, le module d'authentification (73) notifie a l'etape 906 le module 
serveur web (63) que 1'authentification est reussie. Celui-ci emet a l'etape 907 a 
destination du module script ENUM (75) une requete de lecture du profil ENUM. Le 
script ENUM (75) emet une demande d'interrogation a l'etape 908 au module de 
gestion de protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonne 

30 ENUM transformee sous forme de domaine (transformation du numero de telephone 
E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion 
de protocole DNS (62) qui joue le role d'un RESOLVER interroge (etape 909), si les 
informations ne sont pas deja dans son cache suite a une consultation precedente, a 
I'aide du protocole standard DNS (requete DNS Query), le serveur DNS de niveau 0, 
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le serveur DNS de niveau 1, puis le serveur DNS de niveau 2 via son module de 
protocole DNS (32). De preference, pour gagner en efficacite, les donnees d'un DNS 
sont chargees dans la m&noire vive du serveur (31). Si l'abonne ENUM est 
effectivement enregistre dans le serveur DNS (31) du fournisseur de service ENUM 
5 (30), le module de gestion de protocole DNS (32) retourne a I'&ape 910 le/les 
enregistrement(s) NAPTR conrespondant(s) . Le module de gestion de protocole DNS 
(62) se charge de les retransmettre vers le module script ENUM (75) & l'etape 91 1. Ce 
dernier analyse et interprete le/les enregistrement(s) NAPTR, par exemple: 

10 SORIGIN 9.5.8.3.5.0.6.9.2.3.3.el64.arpa. 
INNAPTR100 10 "u" 

'4dap+E2U""^+33296053859$!ldap://ldap.fo^ 

Le script ENUM d&ecte qu'il s'agit d'un service LDAP. Par consequent, le 

15 module script ENUM (75) emet k l'etape 912 a destination du module de gestion 
protocole LDAP (64) une requete LDAP de demande de connexion vers le serveur 
LDAP reference par l'URI "ldap://ldap.fournisseurA.fr". Ce dernier emet a l'etape 913 
une requete "Bind" a destination du module protocole LDAP (35) du serveur annuaire 
LDAP (34) du fournisseur ENUM A (30). Le module protocole LDAP(35) accepte la 

20 connexion a l'etape 914. Le module de gestion de protocole LDAP (64) 6met alors a 
l'etape 915 a destination du module protocole LDAP (35) la requete LDAP "Search" 
en fournissant le numero E.164 de l'abonne ENUM en argument. Le module protocole 
LDAP (35) interroge la base de donnees LDAP (36) a l'etape 916 puis retourne (a 
l'etape 917) Tensemble des informations concernant Tabonn6 ENUM au module 

25 protocole LDAP (35) qui lui-meme les retourne (etape 918) au module de gestion de 
protocole LDAP (64). Ce dernier retourne les informations a l'etape 919 au script 
ENUM (75) qui se charge de les mettre sous une forme comprehensible pour l'abonne 
ENUM avant de les transmettre (h l'6tape 922) vers le serveur web (63). Le serveur 
t616charge ensuite la page web generee dynamiquement k l'etape 923 sur le terminal 

30 web (8) de TabonnS ENUM. En parallele, le module de gestion de protocole LDAP 
(64) envoie a l'etape 920 une demande de deconnexion au serveur LDAP (34) via une 
requete "Unbind". Le module de protocole LDAP (35) confirme la deconnexion h 
l'etape 921. 
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La Fig. 13 decrit la procedure de modification manuelle de profil ENUM 
lorsque ce dernier est stocks dans un annuaire LDAP. La encore, une modification de 
profil ENUM par un terminal autre qu'un PC peut bien entendu etre envisagee. 

L'abonne ENUM ayant precedemment consulte le contenu de son profil ENUM 
5 au moyen de la procedure d6crite ci-dessus, peut decider de le modifier. Pour ce faire, 
il modifie localement dans la page web affichee sur son terminal web (8) les attributs 
de ses services ENUM, les priories, ajoute des services ou en supprime. II valide ses 
modifications de profil a l'etape 1000 et les informations sont fournies au serveur web 
(63). Ce dernier transmet l'ensemble de ces informations a l'&ape 1001 au module 

10 script ENUM (75). Ce dernier emet une demande d'interrogation a l'etape 1002 au 
module protocole DNS (62) en fournissant en argument l'adresse E.164 de l'abonne^ 
ENUM transformed sous forme de domaine (transformation du numero de telephone 
E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion 
de protocole DNS (62) qui joue le r61e d'un RESOLVER peut interroger, si les 

15 informations ne sont pas deja dans son cache suite a une consultation pr£c6dente (a 
l'etape 1003) avec le protocole standard DNS (requSte DNS Query) le DNS niveau 0, 
puis le DNS niveau 1, avant d'interroger le DNS niveau 2 via son module de protocole 
DNS (32). Pour gagner en efficacite, les donnees d'un DNS sont chargees dans la 
memoire vive du serveur DNS (31). Si l'abonn6 ENUM est effectivement enregistre 

20 dans le DNS (31) du fournisseur de service ENUM (30) le module protocole DNS 
(32) retourne a l'etape 1004 le/les enregistrements NAPTR correspondant(s). Le 
module de gestion de protocole DNS (62) les retransmet alors vers le module script 
ENUM (75) a l'etape 1005. Ce dernier analyse et interprete le/les enregistrement(s) 
NAPTR, par exemple : 

25 

SORIGIN 9.5.8.3.5.0.6.9.2.3.3.el64.arpa. 

INNAPTR100 10 "u" 

"ldap+E2U""! A .+33296053859$!ldap://ldap.foumisseurA.fr/cn=33296053859!" 

30 Le module script ENUM (75) detecte qu'il s'agit d'un service LDAP. Le 

module script ENUM (75) emet alors (etape 1006) a destination du module protocole 
LDAP (64) une requete LDAP de demande de connexion au serveur LDAP r6ferenc6 
par l'URI "ldap://ldap.fournisseurA.fr". Ce dernier emet a l'etape 1007 une requete 
"Bind" a destination du module protocole LDAP (35) du serveur annuaire LDAP (34) 
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du fournisseur ENUM A (30). Le module protocole LDAP(35) accepte la connexion k 
l'ftape 1008. Le module protocole LDAP(64) emet alors k I'etape 1009 a destination 
du module protocole LDAP (35) une requete LDAP "Search" en fournissant le 
numero E.164 de l'abonnS ENUM en argument. Le module protocole LDAP (35) 
5 interroge la base de donnees LDAP (36) a I'etape 1010 puis retourne a I'etape 1011 
Fensemble des informations concemant l*abonne ENUM au module de gestion de 
protocole LDAP (35). Ge dernier les retourne a I'etape 1012 vers le module de gestion 
de protocole LDAP (64) qui lui-meme les retourne (6tape 1013) au module de script 
ENUM (75). Celui-ci les compare avec les informations fournies via le web par 

10 Tabonn6 ENUM et determine l'operation a effectuer au format LDAP et transmet une 
demande de modification k l'6tape 1014 a destination du module de gestion de 
protocole LDAP (64). Ce dernier envoie une requete LDAP "Modify" a 1'dtape 1015 k 
destination du module protocole LDAP (35) qui lui-meme emet a P6tape 1016 une 
demande d'ecriture dans la base de donnees (36). Celle-ci accepte la mise a jour et la 

15 confirme (etape 1017) au module protocole LDAP (35). Ce demier transmet (etape 
1018) la confirmation/infirmation de mise a jour au module de gestion de protocole 
LDAP (64) qui la retourne (etape 1019) au module script ENUM (75). Celui-ci gendre 
alors la page web de confirmation de modification avant de la transmettre au serveur 
web (63). Le serveur t&echarge cette page (6tape 1023) au terminal web (8) de 

20 l'abonne ENUM. En parallels le module protocole LDAP (64) envoie (etape 1020) 
une demande de deconnexion au serveur LDAP (34) via une requete "Unbind". Le 
module de protocole LDAP (35) confirme la deconnexion a T6tape 1021 . 

Bien que la procedure de mise a jour d'annuaire LDAP ait <5te illustrte pour une 
25 procedure « manuelle », il va de soi qu'une mise a jour automatique de 1'annuaire 
LDAP au moyen de 1' automate de configuration (74) peut egalement etre envisagee. 

Bien que Finvention ait 6t& essentiellement decrite dans le cadre de Papplication 
« ENUM » et de la mise k jour d'un profil ENUM , il est clair pour Phomme du metier 
30 qu'elle peut s*etendre a la mise k jour d'un ou plusieurs enregistrement(s) de 
ressource(s) (RR) dans un serveur DNS (ou LDAP), tels que definis au paragraphe 
3.2.2 du document RFC 1035 precis et repris dans la table ci-apres : 
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Type de RR 


Valeur 


Signification 


A 


1 


Addresse IP d'une machine 


NS 


2 


Nom de serveur gere par une autorite administrative 


MD 


3 | 


Serveur Mail de destination 


MF 


4 


Serveur Mail de reroutage 


CNAME 


5 


Nom canonique pour un alias 


SOA 


6 


Marque le debut d'une zone d'autorite 


MB 


7 


Nom de domaine d'une boite eMail 


MG 


8 


Membre de groupe de mail 


MR 


9 


Nom de domaine de renommage d'un mail 


NULL 


10 


Resource record NULL 


WKS 


11 


Description de service bien connu 


PTR 


12 


Pointeur sur un nom de domaine 


HINFO 


13 


Information sur une machine informatique 


MINFO 


14 


Information sur une boite mail 


MX 


15 


Echange de mail 


TXT 


16 


Chaines de caracteres 



Pour un enregistrement de ressource donne, la mise k jour pourra porter sur un 
ou plusieurs champs de cet enregistrement, tels que d6fmis dans le document RFC 
1035precite. 

5 II faut noter que si la mise a jour d'enregistrementts) de ressources autre(s) que 

NAPTR est envisag6e, de nouveaux modules similaires au module « Script ENUM » 
(75) et « automate de configuration ENUM » (74) doivent etre ajoutSs pour traiter 
chacun de ces enregistrements. 
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REVENDICATIONS 

1) Systeme de consultation et/ou de mise a jour d'un enregistrement stocks dans 
5 une premiere base de donnees (33, 36), ledit enregistrement comprenant un ou une 

pluralite d'enregistrements de ressources (RR), ladite premiere base de donn<§es etant 
h^bergee par un serveur de noms de domaine, dit serveur DNS, ou un serveur 
d'annuaire, dit serveur LDAP, pouvant etre accede par indirection k partir d'un 
serveur DNS, caracterise en ce qu'il comprend : 
10 - des moyens de communication (1 150, 53-59, 61,63) permettant audit systeme 

de recevoir d'un terminal de telecommunication une demande de consultation et/ou de 
modification dudit enregistrement ou une programmation d'une telle demande ; 

- des moyens de controle (1175, 74, 75) adaptes a determiner a partir de ladite 
demande de consultation et/ou de modification transmise au dit systeme ou 

15 prealablement programmee dans ledit systeme, un nom de domaine et une operation & 
effectuer sur ledit enregistrement ; 

- des moyens de gestion de protocole (1 162, 62, 64) adaptes a rechercher a partir 
dudit nom de domaine, Tadresse IP dudit serveur hebergeant ladite premiere base de 
donnees et, en fonction de ladite operation, k transmettre au dit serveur une requete de 

20 lecture ou de mise a jour dudit enregistrement. 

2) Systeme selon la revendication 1, caracteris6 en ce qu'il comprend des 
moyens d'authentification (1173, 73) adaptes & authentifier au niveau applicatif 
r&netteur de ladite demande a partir d' informations d'authentification stock6es dans 

25 une seconde base de donnees (1 170,70) locale ou distante. 

3) Systeme selon la revendication 2, caract6ris6 en ce que, l^metteur de ladite 
demande ayant ete authentifie, lesdits moyens de gestion de protocole sont adaptes a 
transmettre une requete en consultation selon le protocole DNS (DNS Query) audit 

30 serveur DNS, la requete ayant pour argument ledit nom de domaine, et a recevoir une 
premiere r6ponse dudit serveur. 

4) Systeme selon la revendication 3, caract6ris6 en ce que la premiere base de 
donnees etant h6berg6e par ledit serveur DNS, les moyens de controle sont adaptes & 
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extraire de ladite premiere reponse une information contenue dans ledit enregistrement 
et a la formater pour la transmettre au dit terminal via lesdits moyens de 
communication. 

5 5) Systeme selon la revendication 3, caracterise en ce que, la premiere base de 

donnees etant hebergee par ledit serveur LDAP, les moyens de controle sont adaptes a 
extraire de ladite premiere reponse l'adresse du serveur LDAP. 

6) Systeme selon la revendication 5, caracterise en ce que, lesdits moyens de 
10 gestion de protocole sont adaptes k transmettre une requete en consultation selon le 

protocole LDAP (LDAP Search) audit serveur LDAP et a recevoir de celui-ci une 
seconde reponse. 

7) Systeme selon la revendication 6, caracterise en ce que les moyens de 
15 controle sont adaptes a extraire de ladite seconde reponse une information contenue 

dans ledit enregistrement et a la formater pour la transmettre au dit terminal via lesdits 
moyens de communication. 

8) Systeme selon la revendication 4, caracterise en ce que, les moyens de 
20 controle ayant determine une operation de mise a jour, les moyens de gestion de 

protocole sont adaptes, sur instruction desdits moyens de controle, a transmettre une 
requete en mise a jour selon le protocole DNS (DNS Update). 

9) Systeme selon la revendication 8, caracterise en ce que les moyens de gestion 
25 de protocole sont adaptes a recevoir une reponse de confirmation/infirmation de mise 

a jour du serveur DNS et les moyens de controle sont adapts a formater cette reponse 
de confirmation/infirmation avant d'en ordonner la transmission au dit terminal via 
lesdits moyens de communication . 

30 10) SystSme selon la revendication 7, les moyens de controle ayant determine 

une operation de mise a jour, les moyens de gestion de protocole sont adaptes, sur 
instruction desdits moyens de controle, a transmettre une requete en mise a jour selon 
le protocole LDAP (LDAP Modify). 
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11) Systeme selon la revendication 10, caracterise en ce que les moyens de 
gestion de protocole sont adaptes k recevoir une reponse de confirmation/infirmation 
de mise a jour du serveur LDAP et les moyens de controle sont adaptes a formater 
cette reponse de confirmation/infirmation avant d'en ordonner la transmission au dit 

5 terminal via lesdits moyens de communication . 

12) Systeme selon la revendication 2, caracterise en ce que les moyens de 
controle sont adaptes a stocker dans la seconde base de donnees un profil de 
configuration transmis via lesdits moyens de communication, ledit profil etant 

10 constitue d'une ou plusieurs demandes de modification programmee, chaque demande 
de modification programmee etant associee a au moins une plage temporelle et/ou une 
zone geographique. 

13) Systeme selon la revendication 12, caracterise en ce que lesdits moyens de 
15 controle comprennent un automate de configuration (74) adapte a scruter ladite 

seconde base de donnees et a tester si une mesure de temps appartient a ladite plage 
et/ou une localisation du terminal appartient a ladite zone, et en cas de r£sultat positif, 
k extraire la demande de modification programmee associee et a transmettre aux dits 
moyens de gestion de protocole une demande de consultation de la premiere base de 
20 donnees. 

14) Systeme selon la revendication 13, caract£rise en ce que lesdits moyens de 
gestion de protocole sont adaptes a formuler ladite requete en consultation selon le 
protocole DNS (DNS Query) ou LDAP (LDAP Search) et a recevoir, du serveur 

25 h£bergeant la base de donnees, le contenu dudit enregistrement. 

15) Systeme selon la revendication 14, caracterise en ce que si le contenu dudit 
enregistrement n'est pas conforme k ladite demande de modification programmee, 
lesdits moyens de controle d6terminent une operation a effectuer sur ledit 

30 enregistrement pour le rendre conforme k ladite demande de modification 
programmee et lesdits moyens de gestion de protocole formulent, en fonction de ladite 
operation, une requete de mise k jour de ladite premiere base de donnees selon le 
protocole DNS ou LDAP et Tacheminent vers le serveur hebergeant ladite premiere 
base de donnees. 
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16) Systeme selon la revendication 15, caracterise en ce que lesdits moyens de 
gestion de protocole sont adaptes k recevoir une reponse de confirmation/infirmation 
de mise a jour du serveur Wbergeant la premiere base de donnees et que les moyens 

5 de controle sont adaptes a d&ecter ladite reponse de confirmation/infirmation et a la 
stocker sous forme d'historique dans la seconde base de donnees. 

17) Systeme selon la revendication 16, caracterise en ce que lesdits moyens de 
controle sont adaptes a recevoir une demande de lecture dudit historique, et apres 

10 authentification de l'&netteur de ladite demande par lesdits moyens d'authentification, 
a lui transmettre le contenu dudit historique via lesdits moyens de communication. 

18) Systdme selon la revendication 17, caracterise en ce que lesdits moyens de 
gestion de protocole sont adaptes k recevoir une reponse de confirmation/infirmation 

15 de mise k jour du serveur hebergeant la premiere base de donnees et que les moyens 
de controle sont adaptes a detecter ladite reponse de confirmation/infirmation et a 
transmettre un compte-rendu de ladite operation a un terminal de notification. 

19) Systeme selon Tune des revendications prScedentes, caracterise en ce que 
20 lesdits moyens de gestion de protocole sont adaptes k utiliser un protocole DNS de 

type s6curise (DNSSec). 

20) Systeme selon Tune des revendications precedentes, caracterise en ce qu'il 
comprend une interface RTC et/ou RNIS (51) connectant lesdits moyens de 

25 communication au reseau RTC/ RNIS. 

21) Syst&ne selon la revendication 20, caracterise en ce que lesdits moyens de 
communication comprennent un module de synthese vocale (55) ou un module de 
reproduction de fichiers vocaux (56) permettant de generer un menu vocal, de 

30 reproduire une ou des informations dudit enregistrement sous forme vocale, ainsi 
qu'un module de reconnaissance de signaux DTMF (54) et/ou un module de 
reconnaissance vocale permettant de reconnaitre un choix dans ledit menu vocal. 
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22) Systeme selon la revendication 20, caracterise en ce que lesdits moyens de 
communication comprennent un serveur videotex (57) permettant de gen£rer un menu, 
de saisir une demande de consultation ou de modification dudit enregistrement et de 
reproduire une ou des informations dudit enregistrement ou une reponse de 

5 confirmation/infirmation de mise k jour sous forme de sequences videotex. 

23) Systeme selon la revendication 20, caracterise en ce que lesdits moyens de 
communication comprennent un module d' emission/reception de messages SMS (58) 
permettant de recevoir sous forme de message une demande en consultation ou de 

10 modification dudit enregistrement et de transmettre sous forme de message une ou des 
informations dudit enregistrement ou une reponse de confirmation/infirmation de mise 
&jour. 

24) Systeme selon la revendication 20 comportant une interface RNIS (51), 
15 caracterise en ce que les moyens de communication comprennent un module 

d'emission/ reception (53) d'information usager k usager IUU, permettant de recevoir 
sous forme d'une dite information IUU, une demande en consultation ou de 
modification dudit enregistrement et de transmettre sous forme d'une dite information 
IUU une ou des informations dudit enregistrement ou une nSponse de 
20 confirmation/infirmation de mise a jour. 

25) Systeme selon la revendication 20, caracterise en ce qu'il comprend un 
module fax (59) permettant de transmettre une ou des informations dudit 
enregistrement ou une reponse de confirmation/infirmation de mise a jour. 

25 

26) Systeme selon Tune des revendications 1 & 19, caracterise en ce qu'il 
comprend une interface IP (60). 

27) Systeme selon la revendication 26, caracterise en ce que les moyens de 
30 communication comprennent un serveur Web adapte a transmettre un formulaire 

d' authentication, un formulaire de saisie d'une demande de consultation ou de 
modification dudit enregistrement, de presenter une ou des informations dudit 
enregistrement ou une reponse de confirmation/infirmation de mise a jour sous forme 
de pages Web. 
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28) Systeme selon la revendication 26, caracterise en ce que les moyens de 
communication comprennent un serveur SMTP adapte a recevoir sous forme d' emails 
une demande de consultation ou de modification dudit enregistrement et de 

5 transmettre sous forme d'emails une ou des informations dudit enregistrement ou une 
reponse de confirmation/infirmation de mise k jour. 

29) Systeme selon Tune des revendications precedentes, caracterise en ce que 
les moyens de controle sont adaptes a determiner ledit nom de domaine a partir d'un 

1 0 identifiant d'abonnd. 

30) Systeme selon la revendication 29, caracterise en ce que ledit identifiant 
d'abonnS est le numSro t616phonique E.164 dudit abonne. 

15 31) Systeme selon la revendication 29 ou 30, caracterise en ce que lesdits 

moyens de controle sont adaptes a extraire des informations et a determiner en 
fonction de ladite demande une operation a effectuer sur un enregistrement de 
ressource de type NAPTR. 

20 32) Systeme selon Tune des revendications pr6c6dentes caracterise en ce que 

lesdits moyens de controle sont adapts a extraire des informations et a determiner en 
fonction de ladite demande une operation a effectuer sur un ou plusieurs 
enregistrements de ressource de type A, NS, MD, MF, CNAME, SOA, MB, MG, MR, 
NULL, WKS, PTR, HINFO, MINFO,MX, TXT. 
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